Thread by @rosyna

This is a tweetstorm discussing the new features of altool 4.01 (included with Xcode 11.4), changes to the notarization documentation, and a change to notary service requirements, with the far majority coming directly from user requests

We’ll start with altool 4.01.

1/13

If you used `xcrun altool --store-password-in-keychain-item` you no longer have to supply the --username option when authenticating with --password “@keychain:<item name>” as the username is now grabbed from the keychain item.

This should make scripting easier for organizations.

All versions of altool now default to --transport HTTPS, which is much faster and doesn’t require UDP to be unblocked at the firewall. Specifying a different transport method can be done with altool 4.x (Xcode 11.x), if your org prefers pain.

3/13

While altool has always had the option to have the output returned as xml (plist) or “normal” (plain text), altool 4.01 adds a new json option that can be specified with “--output-format json”. It works with all altool commands.

4/13

When the user’s home folder and the boot volume are the same and APFS, altool 4.01 will now use clone operations (22197175) to safely save an unmodified copy of the file during upload. (To prevent changes to the file from messing up the upload operation)

5/13

Next, I’d like to discuss changes to the notarization documentation.

First, all of the requirements on the main notarization page (developer.apple.com/documentation/…) are linked to the “Resolving Common Notarization Problems” section that explains them in more depth.

6/13

There’s now an explicit note on what happens to plugins if they’re quarantined but not notarized on a user’s computer box.

Specifically, they’ll have to allow the quarantined plugin in the Security & Privacy preference pane.

7/13

There are now multiple references that *explicitly* state that the Xcode UX is only for macOS application targets. All other target types must go through altool (which can be scripted from Xcode).

8/13
developer.apple.com/documentation/…

The bottom of the Customizing the Notarization Workflow document (see above) now very explicitly gives information on how long notarization can take after an upload is completed and steps you can take to reduce notarization time.

9/13

The “Resolving Common Notarization Issues” (developer.apple.com/documentation/…) document has been updated quite a bit based on developer feedback.

For example, there’s now a section dedicated to signing installer packages and avoiding PackageMaker.

10/13

When submitting signed software, make sure the correct certificate type is used. If the software doesn’t have the correct type of cert, the software won’t be notarized.

11/13

The biggest change (developer.apple.com/documentation/…) is that proper entitlement format is now enforced in the notary service and on macOS 10.15.4 and later.

They must be properly formed ASCII-encoded, BOM-less XML files. Xcode enforces that for you, but the codesign tool doesn’t.

12/13

Be safe and always be notarizing!

13/13

One thing I’d like to add is that if you manually pass an entitlement plist file to codesign, you can ensure strict validation passes by running:

plutil -convert xml1 -o new_entitlements.plist old_entitlements.plist

which does sanitizing.

14/13

https://twitter.com/rosyna/status/1245449040080171008?s=21

https://twitter.com/rosyna/status/1245449040080171008