You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think Apple Transporter can be authenticated with either an App Store Connect API key (key id / issuer id / magic file path) or with just -u / -p parameters for an App Specific Password.
You are correct that it can be authenticated with a username and password.
I thought that API keys were strictly superior. Apparently I was wrong. We should add support for those flags.
What makes this less straightforward is that we're using the API key to generate a JSON web token to authenticate in order to check the notarization status and fetch a stapling ticket. If we only have a username and password, I believe we need to call a separate API endpoint to exchange those credentials for a temporary JWT. This should be doable though.
Transporter is being removed as part of #593, as we no longer need it with a pure Rust client for uploading to the Notary API. So closing this.
If you are wondering why we're removing Transporter a) the code and functionality is janky b) it is using a new API and the writing is on the wall (or announced - can't recall which) that notarytool and the App Store Connect API it uses are the future.
If someone can figure out a way to exchange a username/password for App Store Connect credentials to speak to the Notary API, I'll entertain a PR. But this isn't a feature I plan to support given that Apple now offers a fully supported Notary API and the only documented way to use it is with App Store Connect API Tokens.
I think Apple Transporter can be authenticated with either an App Store Connect API key (key id / issuer id / magic file path) or with just -u / -p parameters for an App Specific Password.
The App Specific Password can be created from the https://appleid.apple.com/account/manage page .
This is also supported by XCode
altool
--username / --password flags.This is relevant because it does not require agreeing to additional ToS for App Store Connect.
The text was updated successfully, but these errors were encountered: