macOS notarization and VW plug-in development

[Hans Martin Kern]

macOS Catalina requires code to be signed and notarized. Does this apply to Vectorworks plug-ins, too? Or does VW use the disable-library-validation entitlement? Any hints would be greatly appreciated.

[Hans Martin Kern]

I found that Vectorworks 2020 uses the the "disable-library-validation" entitlement, so plug-ins should load and run (for now). However, it looks like it is lacking the "get-task-allow" entitlement, which enables debugging the plug-ins with Xcode debugger (at least on 10.14.6, lldb can no longer attach to the Vectorworks 2020 process). Any pointers?

Edited October 8, 2019 by Hans Martin Kern

[JBenghiat]

At the moment, the solution is to use csrutil to disable System Integrity Protection. I’m not sure if there is a longer term fix with adjusting entitlements.

[Hans Martin Kern]

Thanks - great idea, will try that one.

Maybe we should encourage VW, Inc. to deliver a VW.app bundle with the get-task-allow entitlement alongside the SDK to avoid this "all-or-nothing" workaround?

[Ryan McCuaig]

So I'm getting that signing and notarizing *are not* required, but I will need to use `csrutil` if I want to debug?

 

I just had a weird situation where VW simply crashed on startup unless I used `codesign` on the binary at `MyLib.vwlibrary/Contents/MacOS/MyLib`. Once that's signed, then VW can proceed but my the debug messages I throw out at registration time aren't showing in console, and I can't see the tools in the Workspace Editor.

 

(Also noticed: the SDK manual still has stuff about .rsrc files in it ... maybe we could figure out a way to document this stuff).

 

macOS 10.15.2 beta, VW 2020 SP2 (513482)

Edited December 3, 2019 by Ryan McCuaig

[Ryan McCuaig]

Hm, the current TesterModule does seem to work without signing / notarization. It must be something testy with having brought this Xcodeproj forward since VW2016. At least I now know it's possible to get SDK plugins in.

[Ryan McCuaig]

🤦‍♂️ ... I had a build step that used `cp -LR` to copy the bundle into a plug-ins folder. I was using `-L` (resolve symlinks) because I didn't understand that `BuildVWR` will symlink when `VWR_MODE="Debug 64"`, which was leading to Xcode producing a bundle that didn't have all the resources, but instead an alias to the .vwr file. (This is the default behaviour in the tester module, if you're compiling debug builds). This `cp` step was breaking Xcode's code signing (ie. none of the string or png resources were present in `MyLib.vwlibrary/.vwlibrary/Contents/_CodeSignature/CodeResources`), so VW freaked out and crashed on startup, presuming malware.

 

(The clue was that manually copying either the tester module library, or my own library, into Plug-Ins made it work).

Edited December 3, 2019 by Ryan McCuaig

[Hippocode]

On 10/17/2019 at 6:37 AM, JBenghiat said:

At the moment, the solution is to use csrutil to disable System Integrity Protection. I’m not sure if there is a longer term fix with adjusting entitlements.

 

Thanks, this helped me out on the developer side. But clients are now reporting Vectorworks prevents them of using the plug-in because of restrictions obviously...

Do we need to modify some settings of our projects for them to be accepted somehow?

[Nicolas Goutte]

24 minutes ago, Hippocode said:

 

Thanks, this helped me out on the developer side. But clients are now reporting Vectorworks prevents them of using the plug-in because of restrictions obviously...

Do we need to modify some settings of our projects for them to be accepted somehow?

 

How do you release your plugins?

 

For example downloading a ZIP per Safari and unpacking the plug-ins, that will lead to quarantined plug-ins.

[Hippocode]

All of them as zipped files (download available on a website or Google Drive). Some bundles support the third party plug-in installer within Vectorworks, which requires the files to be zipped.
I also zip them because some browsers/cloud solutions rename extensions and capital letters in the VWR resource on download/zip which breaks the plug-in.

 

I can't really imagine doing this without these files being zipped 😮

Edited February 4, 2020 by Hippocode

[Nicolas Goutte]

2 minutes ago, Hippocode said:

All of them as zipped files. Some bundles come as an installer with a script using the build in third party support of Vectorworks.
I also zip them because many programs/cloud solutions rename extensions and capital letters in the VWR resource which breaks the pug-in.

 

I can't really imagine doing this without these files being zipped 😮

 

Try to put all those in a DMG and sign the DMG (notarizing it is probably optional, but can be a good way to notarize all applications contained on it).

 

Probably you will need to sign and notarize the installers too.

[JBenghiat]

I have everything zipped for use with the Plug-in Manager install button (FYI, starting with 2018 SP2, you can rename the zip file as .vwlibrary, which the installer will read). So far I haven't had any reports of issues.

[Hippocode]

I removed the quarantaine of the buildvwr tool instead of disabling scrutil so I can see the error messages myself.

Signing alone doesn't do it and I'm unable to create an archive of the plugin in order to get it notarised (Also tried it on the TesterModule sample). Has anyone done this before? I'll see if I can do it manually using terminal instead.

 

 

 

Edited February 7, 2020 by Hippocode

[Nicolas Goutte]

 

2 minutes ago, Hippocode said:

I removed the quarantaine of the buildvwr tool instead of disabling scrutil so I can see the error messages myself.

Signing alone doesn't do it and I'm unable to create an archive of the plugin in order to get it notarised (Also tried it on the TesterModule sample). Has anyone done this before? I'll see if I can do it manually using terminal instead.

 

Plug-Ins by themselves are not apps, so you cannot notarize them (as far as I understand).

 

If you do not or cannot use what @JBenghiat has meant above, you will have to make an installer in such a way that you can sign and notarize it.

[Hippocode]

Using the plug-in manager to install the plug-in did work, thank you for the suggestions.
I'm a bit surprised this works but manually installing doesn't. Maybe Vectorworks removes the quarantaine of the file while copying.

[Nicolas Goutte]

The rule of thumb is: you need notarization if you use Apple tools that trigger GateKeeper.

 

As VW unzips the file by its own mean, not by Apple tools, Gatekeeper is not triggered and therefore the notarization is not needed.

(However, that is a reason (at least for C++-plugins) why VW must advertise that it loads extra code outside the app bundle.)

[Stefan Bender]

Another related issue: After the upgrade to XCode 11 we keep getting build errors in seemingly random plug-ins that are caused by codesigning. The error message says it's about resource forks or finder info.

Some site in the Internet said 

 

>>According to Apple:
>>Note that browsing files within a bundle with Finder’s Show Package Contents command can cause Finder info to be added to those files. 

 

Obviously, we need to do such browsing very often, for instance when we edit .vwstrings or .vs files. 

 

So what can be done to make sure that this codesigning stuff doesn't interfere with the builds? Can we try switching codesigning off? Or try removing the resource forks &c automatically before each build? If we try that, we would need to assign write permissions to the files in the bundle which could interfere with Perforce.

 

Thanks for any help,

 

Stefan Bender

[Nicolas Goutte]

For compiling the plug-ins, you do not need to sign them. As far as I understood, Xcode has a switch somewhere.

Edited March 6, 2020 by Nicolas Goutte

[Nicolas Goutte]

On 3/6/2020 at 1:53 PM, Stefan Bender said:

Obviously, we need to do such browsing very often, for instance when we edit .vwstrings or .vs files. 

 

I have been thinking during the weekend, why apparently we have no such problems (apart not signing our plugins).

 

I have realized that we use the BuildVWR script, even in Debug, as PostBuild-Step. That means an intermediary step between editing and the created plug-in, even inside a .vwr folder.

 

Alternatively, you could try using editors not creating resources, but that would probably mean you have to change your tools, so that is probably not a realistic option.

[Stefan Bender]

I just got a mail from Vlado who suggested changing some project setting (see attachment). I'm  rebuilding the plug-ins and see if it works.

[JBenghiat]

A few addendums to this conversation.

 

Stefan's post above new seems to be crucial. This past week, without updating the OS or VW, plug-ins that were code signed suddenly stopped working with VW. This includes one of my plug-ins as well as the batch encryption library that comes in the current beta SDK. You can actually see plug-ins that will fail by showing package contents and looking for a code signing folder.

 

I also upgraded my system recently to a machine with a security chip. Note that setting options in the Startup Security Utility  https://support.apple.com/en-us/HT208198 do not affect System Integrity Protection, which still needs to happen from the command line. It took me a while to figure this out an get the debugger to attach to VW again.