Author Topic: 2014 a pain in the...  (Read 31132 times)

0 Members and 1 Guest are viewing this topic.

gile

  • Gator
  • Posts: 2507
  • Marseille, France
Re: 2014 a pain in the...
« Reply #45 on: April 03, 2013, 01:23:35 PM »
Quote
That said, and since this is not specified in the online help, I suspect that TrustedPaths is used as a second stage filter... Meaning that, in the example of a LISP (not sure what code file(s) you're wanting to load), the file path would need to be qualified in both SFSP (in order to be found), and TrustedPaths (for authorization).

Admittedly, speculation on my part... If someone knows better, please feel free to correct.

I do confirm, when I said "it works fine" I forgot to said the folder was also added to seach paths. I was an evidence in my mind.
Look at your seach paths, you'd also find the paths to the 'applicationplugins*.bundle' folders even they are trusted by default.
Speaking English as a French Frog

BlackBox

  • King Gator
  • Posts: 3770
Re: 2014 a pain in the...
« Reply #46 on: April 03, 2013, 01:53:59 PM »
all this could have been avoided if the documentation stated the paths need to be in BOTH places

I've already brought this to Dieter's attention, and provided him a link to this thread as reference. Hopefully, we'll see a change to the online docs soon. *wishful thinking*



Look at your seach paths, you'd also find the paths to the 'applicationplugins*.bundle' folders even they are trusted by default.

As I understand it, Autoloader programmatically appends implicitly trusted paths, in addition to explicitly defined SupportPath XmlAttribute paths (as defined within PackageContents.xml within each .bundle)... So in theory, these paths are not included by the author of the Profile's SFSP, but instead added at startup.
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: 2014 a pain in the...
« Reply #47 on: April 03, 2013, 03:01:49 PM »
Anyone know if the trusted path thingy fixes the old issue of loading DVB files from shared folders? I know VBA isn't that much used anymore, just asking if the trusted folders actually has some usefulness.

If not: This thread clearly indicates just how useless such a security measure is. All it actually accomplishes is that it: gets turned off (i.e. SecureLoad=0); or the user explicitly sets all paths to be trusted (i.e. TrustedPaths=A:\...;B:\...;C:\...;......... in effect turning it off also); or the admin/user has yet another setting to change to exactly the same thing as they'd have set in the SFSP. I cannot see a single other possible use for such a less-security measure.

As I said in my previous post: ADesk went too far, adding extra complexity for less benefit. In effect causing less security with more admin/support problems and more user irritation. Exactly the opposite of what they were going for ... we hope!
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

huiz

  • Swamp Rat
  • Posts: 913
  • Certified Prof C3D
Re: 2014 a pain in the...
« Reply #48 on: April 03, 2013, 03:09:06 PM »
This is just a way to force every developer to use the new autoload system and the plugin exchange system.


The conclusion is justified that the initialization of the development of critical subsystem optimizes the probability of success to the development of the technical behavior over a given period.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: 2014 a pain in the...
« Reply #49 on: April 03, 2013, 03:14:42 PM »
This is just a way to force every developer to use the new autoload system and the plugin exchange system.
Yes, I figured as much. But what they failed to realize is that most admin use stuff like an ACad.LSP or ACadDoc.LSP in a shared folder to ensure certain settings are properly adjusted for all in the company. So now the admin also have to create their own form of "plugin" simply to set company-wide settings, i.e. disallowing a shared common settings code (seeing as the autoloader would either need to be in one of the local plugins folders or the trusted paths & SFSP need to be adjusted to point to the shared folder - again defeating the purpose).
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: 2014 a pain in the...
« Reply #50 on: April 03, 2013, 03:44:00 PM »
This is just a way to force every developer to use the new autoload system and the plugin exchange system.

I'm not so certain.  From other discussions, this could be groundwork being laid to ensure compatibility with future government and/or industry regulations.  The presence of security, regardless of present effectiveness, may be a requirement in the near future so this allows AutoDesk to check off the "Yes, we have that" box without scrambing around at the last minute and coming up with something *worse* (yes, that is always an option).  It also gives them real-world feedback to build upon without having to bother with extensive NDA creation and enforcement.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

andrew_nao

  • Guest
Re: 2014 a pain in the...
« Reply #51 on: April 03, 2013, 04:17:47 PM »
But what they failed to realize is that most admin use stuff like an ACad.LSP or ACadDoc.LSP in a shared folder to ensure certain settings are properly adjusted for all in the company.

thats me...
and my shared files run out of F:\acad\...

now that i have it working on my work station i have to now find a guinea pig to upgrade and see if i can get this working on their station.

i have no idea what this plugin business is about though. i hope its not a difficult thing and pray that there is enough documentation on it

BlackBox

  • King Gator
  • Posts: 3770
Re: 2014 a pain in the...
« Reply #52 on: April 03, 2013, 04:40:34 PM »
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: 2014 a pain in the...
« Reply #53 on: April 04, 2013, 01:16:03 AM »
I can't really understand what's more "secure" about such a plugin as opposed to an acaddoc.lsp file in a support folder.
  • It's not as if it's a "secret" about how to create the XML description file.
  • The file doesn't need some certification (like Window's asks for on certain installs like drivers - and we all know how that works: "What, this driver isn't certified? Agggh, just click yes damit! What the heck else am I going to do? Not use my PC?").
  • Nowhere is the user asked if these plugins are to be loaded - if they're in that folder they get access to all of acad.
  • They're a lot more work for admin to get their job done, so chances are admin are going to find a work-around to circumvent the "security" - probably making it worse than it was before.
  • According to this, the plugins can only be installed in local folders (under %APPDATA%). So this necessitates the admin to COPY code to each workstation individually - no more one place with latest code: Now have to make sure each workstation has the latest update. (Unclear if these folders could be changed to allow for a networked shared folder) So some workstation may still be running old versions, at best only causing incompatibility, but could also be causing less security.
From other discussions, this could be groundwork being laid to ensure compatibility with future government and/or industry regulations.
And we all know how "informed" those things can be  :lmao: . It's usually as if the legislators think that computers work the way depicted in those NCIS/CSI/etc. farces!  :ugly: I shudder to think what they actually have in mind.
« Last Edit: April 04, 2013, 01:19:44 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

andrew_nao

  • Guest
Re: 2014 a pain in the...
« Reply #54 on: April 04, 2013, 01:30:00 PM »
well im back to square one
none of my lisp files are loading

this isnt working...

Jeff H

  • Needs a day job
  • Posts: 6144
Re: 2014 a pain in the...
« Reply #55 on: April 04, 2013, 02:29:32 PM »
I do not think it will search subdirectories in Support File Search Path so if they have to be in both you would have to provide path to directory containing lisp file.

BlackBox

  • King Gator
  • Posts: 3770
Re: 2014 a pain in the...
« Reply #56 on: April 04, 2013, 02:39:48 PM »
I do not think it will search subdirectories in Support File Search Path so if they have to be in both you would have to provide path to directory containing lisp file.

Correct.

As an example, given a LISP file here:

Code - Auto/Visual Lisp: [Select]
  1. C:\AutoCAD\LISP\2014\Foo.lsp
  2.  

Assuming SecureLoad > 0, TrustedPaths must include at minimum "C:\...". If SFSP includes only "C:\" (not "C:\..." for SFSP), then your LOAD statement must include the relative path in the fileName parameter:

Code - Auto/Visual Lisp: [Select]
  1. (load "AutoCAD\\LISP\\2014\\Foo.lsp")
  2.  

... In order for your LISP file to be found.
« Last Edit: April 04, 2013, 02:45:33 PM by BlackBox »
"How we think determines what we do, and what we do determines what we get."

BlackBox

  • King Gator
  • Posts: 3770
Re: 2014 a pain in the...
« Reply #57 on: April 04, 2013, 02:49:38 PM »
This just highlights the lack of documentation that is clearly needed, especially so for new System Variables, etc. that are tied to such an integral component of basic functionality.

Further, while SecureLoad has merit, this illustrates just how poorly thought out TrustedPaths is, as SFSP *should* be the core of what is implicitly trusted from the outset.



Yes... I've shared this with Autodesk, specifically Dieter.
"How we think determines what we do, and what we do determines what we get."

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: 2014 a pain in the...
« Reply #58 on: April 04, 2013, 03:06:49 PM »
Not sure I understand the problem.  SFSP has always been required for (load ...) if an explicit path isn't provided.  The documentation for the trusted paths makes no mention of modifying any of this behavior, just preventing loading for files which are not in the trusted paths.  These may or may not include the SFSP depending on whether an explicit path is provided for (load ...).  Am I missing something?
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

ronjonp

  • Needs a day job
  • Posts: 7526
Re: 2014 a pain in the...
« Reply #59 on: April 04, 2013, 03:11:37 PM »
Not sure I understand the problem.  SFSP has always been required for (load ...) if an explicit path isn't provided.  The documentation for the trusted paths makes no mention of modifying any of this behavior, just preventing loading for files which are not in the trusted paths.  These may or may not include the SFSP depending on whether an explicit path is provided for (load ...).  Am I missing something?
^ 1+

Windows 11 x64 - AutoCAD /C3D 2023

Custom Build PC