Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace depracated altool with notarytool #53

Closed
MichalMMac opened this issue Jun 8, 2021 · 6 comments
Closed

Replace depracated altool with notarytool #53

MichalMMac opened this issue Jun 8, 2021 · 6 comments

Comments

@MichalMMac
Copy link
Contributor

MichalMMac commented Jun 8, 2021

There is a new command line tool for custom notarization workflow called notarytool. notarytool is a part of Xcode and Xcode Command Line Tools since version 13. Previous notarization utility altool is now deprecated but is is still present in Xcode 13 and probably will be present in future versions (at least for a time).

Differences between tools

Let's compare altool to notarytool.

Uploading the package

  • xcrun altool --notarize-app -f file_path --primary-bundle-id bundle_id
  • notarytool submit file-path [--wait --no-s3-acceleration]

There is no need to specify bundle_id when using notarytool.

notarytool has a new --wait switch which makes the tool wait until notarization process finishes server side. More on this later.

notarytool uses Amazon S3 for package upload by default. This can be turned off with --no-s3-acceleration switch.

Authentication

Apple ID

  • altool: -u username [-p password] [--asc-provider name | --team-id id | --asc-public-id id]
  • notarytool: --apple-id apple-id [--password app-specific-password] --team-id team-id -p profile-name [--keychain keychain-path]

Main difference here is the way to identify the provider when AppleID belongs to multiple providers.
altool in Xcode 12.5 and 13 has three ways to do it --asc-provider (we currently use this), --asc-public-id and --team-id. notarytool has only the --team-id option.

notarytool can use a "profile" to authenticate using the credentials stored in keychain via the store-credentials command. Credentials in keychain can be in a form of apple-id + password or api-key + api-key-id + api-issuer-uuid.

API access

  • altool: --apiKey api_key --apiIssuer issuer_id
  • notarytool: --key key-path --key-id key-id --issuer issuer

Only diffrence here is altool searches for private key is several known directories but for notarytool path must be provides explicitly with --key option (or be stored in keychain and obtained with --profile option).

Wait for notarization

To find out the notarization result current munki-pkg implementation uses altool to poll the notarization service using altool --notarization-info command.

notarytool has a new wait functionality.

  • You can use --wait option together with notarytool submit subcommand. notarytool waits indefinitely until the server side notarization process finishes.
  • There is a dedicated subcommand: notarytool wait which does the same after the package has been submitted.

Additionally --timeout option can be added to prevent the notarytool to wait for longer than desired periods of time.

Replacement strategies

There are multiple strategies how to replace altool with notarytool in munki-pkg:

  • Keep using altool in munki-pkg main branch for now. I will replace the altool for notarytool in my forked munki-pkg repo, open a PR which would be merged into munki-pkg when time is right (one or two years from now perhaps). I am in favor of this approach.
  • Adjust the code to support both altool and notarytool. Tool selection could be manual via option or automatic depending on Xcode version installed. This is going to introduce additional complexity.
  • Replace altool with notarytool ASAP (after final version of Xcode 13 is released this fall). This would add the requirement to run Xcode 13 or newer to use notarization functionality within munki-pkg.
@gregneagle
Copy link
Contributor

Sadly you'll likely have to support both altool and notarytool -- at least for a while. Can't assume everyone has Xcode 13, and shouldn't wait for altool to actually disappear. :-(

@MichalMMac
Copy link
Contributor Author

MichalMMac commented Jun 8, 2021

Of course. I was about to dive into it but you are too fast 😁

@gregneagle I went over the man pages. Most of the options overlap but there are differences. I laid out possible ways forward. Supporting both altool and notarytool within the munki-pkg is definitely possible but it is going to add more complexity. Just chaing the code to use only notarytool at the some point in the future might be less user friendly (They might need to update keys in build-info in existing projects.) but more munki-pkg project friendly. I don't have strong preference on this. Complex sounds more fun 😅

First of all I should probably update the documentation (especially the links to Apple notarization docs).

@YesThatAllen
Copy link
Contributor

I missed the memo, until I saw a reminder in macadmins slack, that come Nov 1 2023, users won't have a choice to use the old way.

https://developer.apple.com/news/?id=y5mjxqmn

As announced last year at WWDC, if you notarize your Mac software with the Apple notary service using the altool command-line utility or Xcode 13 or earlier, you’ll need to transition to the notarytool command-line utility or upgrade to Xcode 14 or later. Starting November 1, 2023, the Apple notary service will no longer accept uploads from altool or Xcode 13 or earlier.

So, a solution which replaces altool, vs giving an option, could be locked behind a readme/release.

@YesThatAllen
Copy link
Contributor

The code in the notarytool https://github.com/munki/munki-pkg/compare/notarytool is working well for me.

A trailing space was removed when printing error messages here "apple_id + team_id + password or keychain_profile" but there's no PR to comment on (and its pretty trivial vs "does the code notarizing or not")

I wonder.. would the author, @strlng or maybe the most recent committer @g-bougard care to open a PR to main for review?

and @gregneagle tagging the current main as altool or 1.0, etc could allow people who aren't ready for the change to target that, vs having to open issues asking for compatibility.

@g-bougard
Copy link
Contributor

g-bougard commented Dec 1, 2023

I guess this is my fault for the missing space, sorry for that ;-)

@gregneagle I can make the PR if you want unless you want to merge it yourself (and don't forget to fix the missing space issue if you do).

Anyway I agree with @YesThatAllen , that branch should now be in main as altool is no more supported by Apple notarization.

P.S.: Oups sorry, I missed @string still made the PR ;-)

@gregneagle
Copy link
Contributor

Addressed by today's merge commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants