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

0 Members and 1 Guest are viewing this topic.

gile

  • Gator
  • Posts: 2507
  • Marseille, France
Re: 2014 a pain in the...
« Reply #15 on: April 02, 2013, 06:06:27 PM »
Hi,

I tried with a folder containing an acaddoc.lsp file and some other ones added to TRUSTEDPATHS and it works fine.
Speaking English as a French Frog

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: 2014 a paint in the...
« Reply #16 on: April 02, 2013, 07:03:11 PM »
Also worthy of note, is this line from the TRUSTEDPATHS documentation:

Quote
When TRUSTEDPATHS includes a folder that ends with \... (backslash and three dots), all of its subfolders are also trusted.

Example:

Code: [Select]
(setvenv 'trustedpaths "F:\\...")

Code: [Select]
(setvenv 'trustedpaths "A:\\...;B:\\...;C:\\...;D:\\...;E:\\...;F:\\...;G:\\...;H:\\...;I:\\...;J:\\...;K:\\...;L:\\...;M:\\...;N:\\...;O:\\...;P:\\...;Q:\\...;R:\\...;S:\\...;T:\\...; "  )
:evil:
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

BlackBox

  • King Gator
  • Posts: 3770
Re: 2014 a pain in the...
« Reply #17 on: April 02, 2013, 07:13:00 PM »
Code: [Select]
(setvenv 'trustedpaths "A:\\...;B:\\...;C:\\...;D:\\...;E:\\...;F:\\...;G:\\...;H:\\...;I:\\...;J:\\...;K:\\...;L:\\...;M:\\...;N:\\...;O:\\...;P:\\...;Q:\\...;R:\\...;S:\\...;T:\\...; "  )
:evil:

You read my mind, for if/when the attempt to utilize this new feature becomes intolerable.  :kewl:
"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 #18 on: April 02, 2013, 07:22:28 PM »
Code: [Select]
(setvenv 'trustedpaths "A:\\...;B:\\...;C:\\...;D:\\...;E:\\...;F:\\...;G:\\...;H:\\...;I:\\...;J:\\...;K:\\...;L:\\...;M:\\...;N:\\...;O:\\...;P:\\...;Q:\\...;R:\\...;S:\\...;T:\\...; "  )
:evil:

You read my mind, for if/when the attempt to utilize this new feature becomes intolerable.  :kewl:

More specifically:

Code - Auto/Visual Lisp: [Select]
  1.  
  2.  
  3. (defun c:TrustEverything ()
  4.   (princ "\rTRUSTEVERYTHING ")
  5.   (setvar
  6.     'trustedpaths
  7.     (apply
  8.       'strcat
  9.       (mapcar (function
  10.                 (lambda (x) (strcat (vl-princ-to-string x) ":\\...;"))
  11.               )
  12.               '(A B C D E F G H I J K L M N O P Q R S T U V W X Y Z)
  13.       )
  14.     )
  15.   )
  16.   (prompt "\n... Maybe you should have backed this up first. Just saying. ")
  17.   (princ)
  18. )
  19.  

** Tested on AutoCAD 2014
« Last Edit: April 02, 2013, 07:32:26 PM by BlackBox »
"How we think determines what we do, and what we do determines what we get."

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: 2014 a pain in the...
« Reply #19 on: April 02, 2013, 07:49:27 PM »
Or perhaps:
Code: [Select]
(defun c:trustall ( / fso lst )
    (if (setq fso (vlax-create-object "scripting.filesystemobject"))
        (progn
            (vl-catch-all-apply
               '(lambda ( )
                    (vlax-for drv (vlax-get fso 'drives)
                        (setq lst (vl-list* ";" (vlax-get drv 'driveletter) ":\\..." lst))
                    )
                )
            )
            (vlax-release-object fso)
            (setvar 'trustedpaths (apply 'strcat (cdr lst)))
        )
    )
)
(vl-load-com)

nobody

  • Swamp Rat
  • Posts: 861
  • .net stuff
Re: 2014 a pain in the...
« Reply #20 on: April 02, 2013, 10:44:37 PM »
Y'all have me scared to upgrade lol

JNieman

  • Water Moccasin
  • Posts: 1655
Re: 2014 a pain in the...
« Reply #21 on: April 02, 2013, 11:06:42 PM »
Yeah .. I looked at the securepath option and abandoned. These new security features may be wanted by others .. but not me. :-P

Thanks for the solution to his "feature".

I was hoping there was an easy disablement.


My mistake, I replied before reading the entirety of the thread.  I think Kerry hit the nail on the head with the permanent ham-fisted solution.  This is not an elegant 'feature' and as such it deserves an equally inelegant/brute-force solution.

I can't imagine what the hell they were thinking with this one...

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: 2014 a pain in the...
« Reply #22 on: April 03, 2013, 03:06:44 AM »
< .... >   I think Kerry hit the nail on the head with the permanent ham-fisted solution.  < ... >

No, No, No, NO ... I'm still looking for a good sarcasm icon, or at least a tongue-in-cheek icon to post with that comment.
My post was more in the vein of 'I know this is going to happen' rather than 'I suggest you do this'
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: 2014 a pain in the...
« Reply #23 on: April 03, 2013, 03:46:35 AM »
My post was more in the vein of 'I know this is going to happen' rather than 'I suggest you do this'
Funny aint it? Adesk goes and introduces some "security" measure and the very first thing the users are looking for is: "how to break it so we can actually use the damned product"
 
Reminds me of  having to set administrator rights simply so acad would start! I think adesk is going beyond the opposite way now. There's always a balance needed between functionality and security (otherwise you get no usability as well as no security), and I think adesk has just tipped that scale into the security side.
They're making the mistake stipulated here: http://www.forbes.com/sites/danwoods/2013/03/11/why-security-without-usability-leads-to-failure
Quote
“You cannot have usability in a security system without sensitivity to the work being done,” said Gonen. “When CISOs focus on assets and technical mechanisms, not on the experience of users in doing their work, systems fail from day one and users immediately start working around approved practices, which increases risk even further.”
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 #24 on: April 03, 2013, 08:59:16 AM »
nothing i do makes this trustedpaths option work
my files simply wont load unless the paths are in the support file search path

BlackBox

  • King Gator
  • Posts: 3770
Re: 2014 a pain in the...
« Reply #25 on: April 03, 2013, 09:16:42 AM »
So just to confirm....

Try (setvar 'secureload 0).

also tried that, didnt seem to do anything even setting it to 0 didnt help
anything loading out of the "trustedpaths" path, wont load.  (for me anyway)
im also on a 30 day trial as im waiting for my copy to arrive in the mail

Is anyone else also experiencing the behavior here, where executable files are not being loaded outside of TrustedPaths when SecureLoad is zero (0)?
"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 #26 on: April 03, 2013, 09:19:34 AM »
nothing i do makes this trustedpaths option work
my files simply wont load unless the paths are in the support file search path

This requires clarification... How have you been attempting to load your 'files' if not in SFSP?

Specific example would be helpful.
"How we think determines what we do, and what we do determines what we get."

andrew_nao

  • Guest
Re: 2014 a pain in the...
« Reply #27 on: April 03, 2013, 09:26:43 AM »
nothing i do makes this trustedpaths option work
my files simply wont load unless the paths are in the support file search path

This requires clarification... How have you been attempting to load your 'files' if not in SFSP?

Specific example would be helpful.

i have my files listed in the support path to make them work, if i list them in trustedpaths they dont work

BlackBox

  • King Gator
  • Posts: 3770
Re: 2014 a pain in the...
« Reply #28 on: April 03, 2013, 09:36:52 AM »
nothing i do makes this trustedpaths option work
my files simply wont load unless the paths are in the support file search path

This requires clarification... How have you been attempting to load your 'files' if not in SFSP?

Specific example would be helpful.

i have my files listed in the support path to make them work, if i list them in trustedpaths they dont work

That suggests that your 'load' call does not include the file path where your file is stored.

I haven't done enough testing to observe that TrustedPaths are, or are not included in LISP's Load function's ability to 'find' the file name parameter in SFSP if not specified, for example:

Code - Auto/Visual Lisp: [Select]
  1. (load "foo.lsp")

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.
"How we think determines what we do, and what we do determines what we get."

andrew_nao

  • Guest
Re: 2014 a paint in the...
« Reply #29 on: April 03, 2013, 10:51:21 AM »
Quote from: Kerry

Code: [Select]
(setvenv 'trustedpaths "A:\\...;B:\\...;C:\\...;D:\\...;E:\\...;F:\\...;G:\\...;H:\\...;I:\\...;J:\\...;K:\\...;L:\\...;M:\\...;N:\\...;O:\\...;P:\\...;Q:\\...;R:\\...;S:\\...;T:\\...; "  )
:evil:

; <-- comments out the rest of the line so this wont work