Apple Gatekeeper notarised distributables

MacOSX and iOS
1

Hi

Apple looks to be furthering gatekeeper protection with additional checks on distributed binaries, we can see some details about it here: https://developer.apple.com/developer-id/ and a little more from Ars here: https://arstechnica.com/features/2018/09/macos-10-14-mojave-the-ars-technica-review/10/#h3

It seems Apple wants to perform some kind of basic review of signed binaries and to then act as a notary on the developer’s signature, vouching for it not containing malware etc, so they can be less dramatic when warning people about the dangers of using programs they’ve downloaded. It’s optional at the moment, but Apple says: “in an upcoming release of macOS, Gatekeeper will require Developer ID signed software to be notarized by Apple.”

Feels a bit like typical Apple nannying/over-reach, but I can see the benefit to consumers and the platform as a whole, so I’ll just go along with this without too much resistance.

I’m wondering if anybody has any experience of this with audio plug-ins, maybe somebody has tried it if they knew about it a while ago, and/or knows what the future implications for audio plug-ins is likely to be when it becomes mandatory.

Thanks
Matt

6 Likes
Debugging Ableton Live
Confusion on Catalina / notarization / hardened run-time - no changes needed after all?
Notarizing after Code-Signing?
Xcode 11 not launching executable
Apple Catalina verification?
2

Feels a bit like making non-app store deployment more of a hassle to me.

1 Like
3

Yes, it will be, but that’s the most likely place for people to unwittingly download a security problem into their Mac so Apple wants to tie it down and I think that’s a fair thing to do as long as we’re not overly inconvenienced as devs (which is what I’m trying to establish).

4

i guess it depends what the process is and how long it takes? my immediate concern is it adding time to beta releases for testers, but from what I can see it’s an automated process rather than requiring human intervention, so that shouldn’t be bad hopefully.

5

Does anybody have success with notarisation via command line tools (xcrun altool) ? (For distribution outside the App Store)

1 Like
6

Yes xcrun altool worked fine here to notarize installer packages. Make sure your binaries inside (vst, au, aax etc.) are all signed otherwise it will be rejected.

2 Likes
7

Is this an automated process with a fast verified vs rejected response?

1 Like
8

okay it feels a little bit like entering unknown terrain …

I was able to notarise a zip file which contains my (previously signed) plugin.component (AU)

crun altool --notarize-app --primary-bundle-id "com.mycompany.notarizationtest1" --username "myapple@account.com" --file testSign.zip

i had to create an app-specific apple password before (never used this feature before, Using app-specific passwords - Apple Support) to use this notarisation tools.

you can check the current state with this command
xcrun altool --notarization-history 0 -u myapple@account.com

You can also use the keyChain to store the password, and download a log-file from the notarisation process, better described here:

according to apple:

You should also attach the ticket to your software using the stapler tool, so that future distributions include the ticket. This ensures that Gatekeeper can find the ticket even when a network connection isn’t available.

But:

While you can notarize a ZIP archive, you can’t staple to it directly. Instead, run stapler against each individual item that you originally added to the archive.

Which I did for the component file:

But I getting this weird message: (for an AudioUnit!!!)

xcrun stapler staple MyPlugin.component

Processing: /Users/username/cpp_projects/MyPlugin/Builds/MacOSX/build/Release/testSign/MyPlugin.component

Stapler is incapable of working with Pro Tools Plug-In files.

currently I ignored the fact the the the “runtime hardened” feature for signing, I’m wondering if the notarisation process “sees” the plugin-binaries as executables at all :-/

Also I checked the verification of the plugin-files, and wasn’t successful

spctl -a -v MyPlugin.component/

MyPlugin.component/: rejected (the code is valid but does not seem to be an app)
4 Likes
9

If this is failing on plug-ins does it suggest we should be only doing it for the installers?

10

I don’t know, the notarisation IS successful, but I wonder if apple detects the binaries as executables, or just as plain data-files.

Notarisation of the installer/pkg can’t be wrong.

Probably I do something wrong, what ever …

11

Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.

https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

Looks like this is coming down the pipe pretty quickly. Anybody doing this successfully for your installers?

12

Update: Notarization will be mandatory for new developers with macOS 10.14.5

Wondering my self what to do, my pkg-installer uses internally a „kind-of“ self-extrating binary which creates the (correctly signed) plugin binaries.

Should i submit the plugins also prophylactically inside a zip-file, so that later the OS recognized them as notarized, after the are created from my installer.

Does someone ever was successful with the verification of a plugin after it was notarized inside a zip file?

13

Is there any hint from apple that plugins are also expected to be submitted to the notarization ? As far as I can see, only apps are mentionned

14

I think installers at least need to be notarized.

15

i’ve managed to get individual plugins / standalone builds notarized. i’m using “app sandbox” and “hardened runtime”. i haven’t managed to get my installer notarized but i’m starting a separate thread for that. i’m posting my steps here in case it helps anyone else.

standalone / auv3 builds

for these (both of which are the same as far as i can tell) i’ve used the following steps:

  1. with either target selected in xcode, “Product” -> “Archive” and wait for build to finish.
  2. from Organizer, click on “Distribute App”
  3. select “Developer ID”,
  4. click “Upload”
  5. select “Automatically Manage Signing”
  6. click “Upload” again.

the product is uploaded to apple and i get an email in a few minutes with the results of the notarization (which passes).

vst/vst3/au

  1. with one of these targets selected in xcode, “Product” -> “Archive”
  2. from Organizer, click on “Distribute App”
  3. select “Build Products”
  4. pick an output directory
  5. open the directory in finder and navigate to the plugin.
  6. create a zip of the target by ctrl-clicking on the target and selecting “Compress…:”
  7. submit the zip archive to apple via the cli - read this entire page before you start. you’ll have to follow the security add-generic-password instructions first before the xcrun altool instructions will work

the product is uploaded to apple and i get an email in a few minutes with the results of the notarization (which passes). i can then staple the ticket via xcrun stapler staple MyApp.(vst|vst3|component)

2 Likes
16

For the VST/VST3/AU did you try and fail to notarise a regular build (i.e. one that just drops out a normal .vst/.vst3/.component build to disk), then find it was necessary to run this process through XCode? For those with fairly bespoke build processes this could be a nightmare to integrate.

17

For the VST/VST3/AU did you try and fail to notarise a regular build (i.e. one that just drops out a normal .vst/.vst3/.component build to disk),

which build type are you referring to? i’m not sure how to do a production/stripped/signed build other than via archive but i’d love to learn.

18

Via command-line utilities

 xcodebuild  -configuration Release   // compile
 strip -x -S pluginBinary  // strip
 codesign -dvv pluginPackage  // code signing

However the notarisation process is a little bit more complex.

Does somebody wants to share a shell script, which notarise the plugin (add to zip, upload to apple), check the notarisation status, and than attaches the notarisation-ticket to the plugin?

Here is what I found so far https://nativeconnect.app/blog/mac-app-notarization-from-the-command-line/

19

There is a notarization script here: https://bitbucket.org/jpommier/notarize/src/default/notarize-app . A bit rough, but still much more convenient than the apple tools.

2 Likes
20

Is it sufficient to notarise just an installer pkg, or do we need to do any binaries in the installer as well? (Or instead). I had the impression from Apple’s documentation it was just the installer but I’m wondering if that isn’t the case reading here.

3 Likes