Apple Gatekeeper notarised distributables

Changing the content of the App-bundle will only invalidate the code signature. Re-signing means running something like:

codesign --force --sign "Developer ID" --options runtime --entitlements mine.entitlements --timestamp DAW.app

where mine.entitlements contains at least:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
	<key>com.apple.security.device.audio-input</key>
	<true/>
	<key>com.apple.security-get-task-allow</key>
	<true/>
</dict>
</plist>

I’ve actually never tried to do that, so something might not work as expected, but that’s the theory.

6 Likes

Theory works. I pulled the entitlements from Studio One 4.5.4 (codesign -d --entitlements :- /Applications/Studio\ One\ 4.5.4.app), added get-task-allow (edited plist below), resigned, and can now attach a debugger as required.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.cs.allow-jit</key>
	<true/>
	<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
	<true/>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
	<key>com.apple.security.device.audio-input</key>
	<true/>
	<key>com.apple.security.personal-information.addressbook</key>
	<true/>
	<key>com.apple.security.get-task-allow</key>
	<true/>
</dict>
</plist>
13 Likes

Just wanted to mention 2 commands to test an installer of binaries :


to test the notarization (note that the result can be positive even without stapled ticket) :

spctl -a -vv -t install myInstaller.pkg

result should be:

"accepted"
source=Notarized Developer ID
origin=Developer ID Installer: Jane Doe

to test if there is a ticket stabled :

xcrun stapler validate myInstaller.pkg

result should be : "The validate action worked!"

6 Likes

Thank you @McMartin & @hill_matthew! Crisis Averted

1 Like

+1 Soooo glad to find this post, just sidestepped issue thanks to you guys!

THIS IS NOT FOR NOTARISING BUT TO ALLOW DEBUGGING WITH NOTARIZED HARDENDED HOST

based on @McMartin I’ve made a shell script for this.

I’ve tested it on Ableton Live and Studio One

Caveats:

  • Once you resign the App, it might ask some permissions again (for example to access its own keychain data)
21 Likes

@ttg thanks for sharing this script!

I asked a colleague (who is more knowledgeable than me about code signing) to show me how to re-sign Ableton Live, and he used the following command:

codesign --force --options runtime --sign - --entitlements new.entitlements Ableton\ Live\ 10.1.2\ Suite.app/

i.e. using an ad-hoc signature (-) and no timestamp.

If you pass --timestamp, then you need a paid Apple Developer ID. At least that’s how I understand the documentation of --timestamp in the man page of codesign:

--timestamp [=URL]
         During signing, requests that a timestamp authority server be contacted to authenticate the time of signing. The
         server contacted is given by the URL value.  If this option is given without a value, a default server provided by
         Apple is used.  Note that this server may not support signatures made with identities not furnished by Apple.
6 Likes

Thanks I’ve updated this gist (and the post). it does work with my private non-paid Apple dev id now!

2 Likes

I had some problems with the notarisation script above after upgrading to catalina.

This one seems to work using the xCode tools:
Reference:
https://nativeconnect.app/blog/mac-app-notarization-from-the-command-line/

if xcrun altool --notarize-app \
    -t osx \
    -f $NAME-installer.pkg \
    --primary-bundle-id 'unknown' \
    -u 'xxxx@xxx.xx' \
    -p $(security find-generic-password -a ${USER} -s Notarization-PASSWORD -w) \
    --output-format xml > 'upload_info_plist.xml'; then
   
   while true; do \
       /usr/bin/xcrun altool --notarization-info `/usr/libexec/PlistBuddy -c "Print :notarization-upload:RequestUUID" upload_info_plist.xml` -u 'xxxx@xxx.xx' -p $(security find-generic-password -a ${USER} -s Notarization-PASSWORD -w) --output-format xml > 'request_info_plist.xml' ;\
       if [[ `/usr/libexec/PlistBuddy -c "Print :notarization-info:Status" request_info_plist.xml` != "in progress" ]]; then \
           break ;\
       fi ;\
       /usr/bin/osascript -e 'display notification "Zzz…" with title "Notarization"' ;\
       sleep 30 ;\
   done
   xcrun stapler staple $(basename $NAME-installer.pkg)
   xcrun stapler validate $(basename $NAME-installer.pkg)
fi

Notarization-PASSWORD is located in the OSX key chain.

Just for the case someone has the same issues.

2 Likes

Be careful only checking for in progress. Sometimes you’ll get an error if you check the status too quickly after uploading. I’m not sure what it depends on, probably their server load.

Indeed, I also got a case the other day running on CI where after several in progress checks it returned to say it didn’t recognise the UUID!!

1 Like

I am a bit confused about the workflow:

This is about an app, (that will additionally install plugins, but I’ll get to that later)

  • notarise the dmg
  • staple the app

Now the staple changes the app bundle (I realised that, because when I was stapling the app inside the dmg I got error 73, which was a problem writing), wouldn’t I have to notarise the dmg again?

If you notarise and staple the DMG you should not need to notarise and staple the app inside it as Apple will inspect that as part of the procedure of inspecting the DMG.

1 Like

Oh, so I can also staple the dmg? I’ll try that. - Yep, worked perfectly!

Thanks for clearing that up.

I’ve just started to try Notarizing. Can someone clear up a small problem for me?
I’m being blocked out of my Apple account because of a password problem, apparently.

I think it’s do to with a password for a specific app, I put in altool as a label then generate one:-

Then I use something like this…

xcrun altool --notarize-app -f "Install.pkg" --primary-bundle-id com.yourapp.pkg --username "YourAppleID" --password "YourAltoolPassword"

From this thread, I believe I don’t need the bundle id, is that correct?

I think I’m meant to create a password for ‘altool’ but the actual password doesn’t work in the command line.
Do I have to put it in the keychain? I don’t understand Mac stuff much. Thanks for any help on this…

You can add your app-specific password to your keychain with a command something like this:
security add-generic-password -a "DAVE_H_APPLE_ID" -w <APP_SPECIFIC_PASSWORD> -s "DAVE_H_KEYCHAIN_NOTARIZATION_PASSWORD"

You can then use it with altoool like this:
--password @keychain:DAVE_H_KEYCHAIN_NOTARIZATION_PASSWORD

Thanks, I’ll try that.
When I create the specific app password what do I put as the ‘label’ ? is it just ‘altool’ ?

The label you enter into the Apple dev website doesn’t matter, that’s just to jog your memory if you end up with a ton of app-specific passwords and need to kill some of them for any reason.

That adds to my confusion a little. Hmm, so how is it “app-specific” if it doesn’t actually matter? How is the app specified then?

It’s just a means to make extra passwords that you can use for specific apps.