Mojave 10-14-5 and Notarization

(Lenny Eiger) #1

I just read about the notarization functions in the next Mojave.
( https://www.macrumors.com/2019/04/08/mac-apps-notarization-macos-10-14-5/ ). I am already annoyed by having to code sign my AppleScript apps that automate things for my customers. If I find a error in my code, or just want to update it for some very good reason, it appears I have to bring it back to my computer to do the changes, then save it with signing, then send it back to the user’s computer, and so on.
Will I now have to send it to Apple as well?
Do you folks understand the ramifications of these changes?
TIA
Lenny

1 Like

(Shane Stanley) #2

The announcement presumably means what it says: signed apps will have to be notiarized. Just how that will be handled for scripts is not yet entirely clear.

0 Likes

#3

Well, it seems that I can’t notarize an applet. Apple’s service gives me this error message:

The executable does not have the hardened runtime enabled.

0 Likes

(Shane Stanley) #4

I suspect you can do but at this stage you will have to sign the applet manually. You will need to specify the runtime option flag, as well as creating an entitlement property list file and passing its path to the --entitlement option. I suspect the only entitlement you will need is com.apple.security.automation.apple-events. And you will probably also need the --timestamp option.

I’m guessing an entitlement file like this should be enough to give scripting plus loading external frameworks:

<?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.automation.apple-events</key>
	<true/>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
</dict>
</plist>

At least, that’s the theory. Post back and let us know how it goes.

1 Like

#5

Hi Shane,

thanks for your answer. After some trying it went well. Here is what I’ve done:

  1. I signed the applet:
    xattr -rc APPLET.app
    codesign -f --deep --options=runtime --timestamp --entitlements Entitlements.plist -s MACDEVID -v APPLET.app
  2. I created a signed disk image (with DMG Canvas) for the applet (maybe not necessary).
  3. Sent the disk image to Apple’s notarization service:
    xcrun altool --notarize-app --primary-bundle-id "COM.NOTARIZATION.ID" --username "your@mail.tld" --password "@keychain:AC_PASSWORD" --file DISKIMAGE.dmg
  4. After successful notarization (checked with the Notarize app) I included the notarization ticket into my disk image:
    xcrun stapler staple DISKIMAGE.dmg

Informations about notarization and how to fill the keychain can be found here: Customizing the Notarization Workflow | Apple Developer Documentation

5 Likes

(Phil Stokes) #7

Here’s an excellent step-through from someone initially facing the same thing with Automator-build apps.

0 Likes

(Shane Stanley) #8

I’m curious how it worked without an entitlements file, but it might be because by default actions inherit a com.apple-based identifier.

0 Likes

(Phil Stokes) #9

I’m still getting to grips with this myself, but as I understand it, you can codesign with the hardened run time flag without adding any extra entitlements

codesign --verbose --force --deep -o runtime --sign "Developer ID Application:xyzzy" /path/to/app.app

Hardening is just a mach-o flag that gets written into the binary. If you want to pass entitlements (like being able to send apple events to other apps), you should be able to build an entitlement plist and feed that to codesign (caveat: theory, I ain’t tested it yet!).

0 Likes

(Shane Stanley) #10

Yes, I was assuming that would be the case with an Automator applet, but of course it doesn’t have to end Apple events.

See earlier in this thread for an example.

0 Likes

(Phil Stokes) #11

Yeah, sorry only saw afterwards that that had already been covered. :+1:

0 Likes