After I mentioned in an earlier post that I had digitally signed the sample LISP file I had provided, this generated some interest. In this post, I’ll explain why you might want to sign your LISP files. In a later post, I’ll explain how to do it.
These days it is standard practice for developers to digitally sign their code. Operating systems and applications are displaying increasingly scary warnings when coming across unsigned code. Here is an example of the sort of message you get when you load an unsigned LISP file into AutoCAD from a location that has not been explicitly configured as a trusted location:
If you’re a CAD Manager dealing with your own internal code, it’s not too onerous to configure AutoCAD in Options > Files such that a folder is trusted by AutoCAD and place your code in there. The folder should be read-only; if it isn’t, AutoCAD warns you when you try to configure it. If you do this, the scary warnings don’t appear to bother and confuse your users, even if your code is unsigned.
Another way a CAD Manager can avoid the warnings is to set the SECURELOAD system variable to 0. That’s generally not recommended because it turns off AutoCAD’s security features. While you’ll probably get away with this, there’s always a chance that a user will load some malware and then you’ll have to explain yourself to management.
If you’re not just using your code internally and it’s going to be used by other parties, then you’re not going to have that level of control over the user environment. In recent AutoCADs it’s possible to set up the installation deployment such that users can’t turn off the security settings. If the CAD Manager at the location using your code has done this, your potential users are going to be presented with unprofessional-looking scary warnings.
If you sign your code, users might still get a warning, but it’s less scary. It identifies you as the verified source of the code so they will have more confidence in picking the Always Load button. Once they’ve done this, other signed code of yours will be automatically trusted.
There’s another important reason you might want to sign your code, and that’s protection against other people’s modification of your code. If somebody edits your LSP file and then gives it to someone who tries to load it, the user is presented with an even scarier warning:
Note that this warning no longer has your name on it. This means it’s possible to protect yourself from people (internal or external) who well-meaningly hack about with your code and then try to blame you when it goes wrong. It also gives a level of protection against your code being infected by malware.
Note that all of the above only applies to AutoCAD 2016 and later. AutoCAD 2014 introduced some LISP loading security measures, but the signature stuff came a couple of releases later. Earlier AutoCAD releases, along with compatibles such as BricsCAD and ZWCAD, will just ignore the digital signature. It’s just a comment in the code as far as they’re concerned.
LISP files with the LSP, MNL, FAS, or VLX file extensions can be digitally signed. There’s a bug in the original iterations of AutoCAD 2016 and AutoCAD 2018 that prevents signed VLX files from working. This was patched later in both releases (2016 SP1 and 2018.0.2), but if you’re distributing your code externally there’s always a chance that your VLX might end up in the hands of somebody using a broken release. Also, VLX files that are digitally signed cannot be loaded into AutoCAD 2015 and earlier, broken or not. You should bear that in mind before distributing signed VLX files. I don’t do it and would advise against it. Thanks, Autodesk.
Given this information, if you decide that signing your LISP is a good idea, watch this space for information on how to do it.