notarytool: No Keychain password item found for profile

Hi! Trying to use notarytool for an app notarization via script on CD pipeline. Build machine has an Xcode 12.5 installed and currently it can't be upgraded. So, our team decided to use utility as standalone binary, placed in the /Applications directory. The command used for notarization: '/Applications/notarytool submit '<path>' --keychain-profile '<profile-name>' --output-format 'json' --wait'. Before running the command above, we saved keychain profile with notarytool store-credentials command. However, future runs of notarization script fail with a message: 'Error: No Keychain password item found for profile: '. But we definitely see it among Keychain entries and 'security find-generic-password -l ' command approves that profile has been saved. Did anyone encounter a similar issue? Can someone suggest what how to cope with this behavior? Thank you in advance for any ideas

Accepted Reply

So, App Store Connect keys helped us resolve an issue Thank you!

Add a Comment

Replies

Are you sure you’re running the CD pipeline in the same login context as you used when running the store-credentials subcommand?

My experience is that a lot of CD pipelines run as root, or run as a specific user but don’t correctly log in as that user [1], and then fail with mysterious keychain errors. A good test here is to add a step in your CD pipeline that runs the find-generic-password command that you mentioned. Is it able to see the item?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] They might switch the BSD execution context, the EUID and so on, but fail to switch the Mac-specific execution context, most notably the security context on which the keychain relies. See Technote 2083 Daemons and Agents for an old but still mostly accurate explanation of the gory details here.

  • Hi @eskimo! Thank you, for your response and suggestions. I ran an additional step in CD pipeline with two commands security find-generic-password -l '<profile-name>' and security find-generic-password -a ' com.apple.gke.notary.tool.com.<profile-name>'. The first one successfully found the entry in the keychain, however, the second one failed. On which result should I rely on?

Add a Comment

Hi @eskimo! Thank you, for your response and suggestions. I ran an additional step in CD pipeline with two commands security find-generic-password -l '<profile-name>' and security find-generic-password -a ' com.apple.gke.notary.tool.com.saved-creds.<profile-name>'. The first one successfully found the entry in the keychain, however, the second one failed. On which result should I rely on?

Also, can anyone suggest the way how to check via Terminal whether profile has been added to keychain successfully?

We have changed a stored profile name, checked whether it is presented in the Keychain, and pushed CD pipelines several times with successful result. However, after some time it failed and continued delivering the same results with mentioned error. So, I make an assumption that notarytool has not enough rights to read something from the Keychain. Should we run it as a root process, or set an owner to root? The pipeline is running in the same user session as store-credentials executed.

Unfortunately I can’t help you out with this. For… well… reasons, I have to authenticate using an API key, so I can’t test stuff that relies on an app-specific password.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for your response, @eskimo. However, do you have any recommendations on where to store App Store Connect API private key?

However, do you have any recommendations on where to store App Store Connect API private key?

notarytool expects to find this in a file whose path you supply via --key; where you place that file is up to you.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

So, App Store Connect keys helped us resolve an issue Thank you!

Add a Comment

I had the very similar issue on our build machine with TeamCity installed. The build and notary script even works smoothly when it is being called manually on the build machine. But when the building process is triggered automatically, such as a nightly build, it failes with:

Info [KEYCHAIN] No Keychain password item found for: AC_PASSWORD

The solution for me was that the keychain profile has to be stored in the login keychain, but not in the default iCloud/Login Items keychain when running the comand "notarytool store-credentials", otherwise the keychain profile, no matter app-specific-password or App Store Connect Key won't be listed by 'security find-generic-password -l '. I think there must be a bug related to "notarytool store-credentials" and "security find-generic-password -l".

  • I have the same problem with an Azure Agent build server. The notary tool works fine when run manually and I can also run the unattended build for a while after that. But when I come back and run a build several days later, the item cannot be found on the keychain. Running the notary tool manually solves the problem and I can run my build again.

    I'm afraid don't really understand what the solution is here? Which keychain should I use to store credentials?

Add a Comment

I had the very similar issue on our build machine with TeamCity installed. The build and notary script even works smoothly when it is being called manually on the build machine. But when the building process is triggered automatically, such as a nightly build, it failes with: Info [KEYCHAIN] No Keychain password item found for: AC_PASSWORD The solution for me was that the keychain profile has to be stored in the login keychain, but not in the default iCloud/Login Items keychain when running the comand "notarytool store-credentials", otherwise the keychain profile, no matter app-specific-password or App Store Connect Key won't be listed by 'security find-generic-password -l '. I think there must be a bug related to "notarytool store-credentials" and "security find-generic-password -l".

The solution for me was that the keychain profile has to be stored in the login keychain

Right.

To start, I recommend that you read TN3137 On Mac keychain APIs and implementations, which explains a lot of the backstory here.

notarytool defaults to using the data protection keychain, which is generally a Good Thing™. However, the security tool always works with file-based keychains. So, if you’re in a situation where you need to manipulate the keychain state using the security tool, it’s best to override that default, configuring notarytool to use a file-based keychain.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

TL;DR

I just found this thread and have a similar issue: Sometimes I run my pipeline two times in parallel (once for arm64 and once for x86_64) on the same machine and then I get this error (xcrun notarytool submit ***.dmg --keychain-profile "org.***.***" --wait -> Error: No Keychain password item found for profile: org.***.***) for one of the pipelines. If I just rerun xcrun notarytool submit ***.dmg --keychain-profile "org.***.***" --wait, it works fine. Is this known issue, if you use the same --keychain-profile multiple times at the same time?

Is this known issue, if you use the same --keychain-profile multiple times at the same time?

I’m not aware of any issues like that.

In what context are you running these jobs? In a script you run from Terminal? Or something else?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Add a Comment

I run it as a direct queue of commands linked with && in the terminal. Up to now the error only happened if I run both in parallel:

Terminal 1 (works almost always):

mkdir arm64 && \
cd arm64 && \
source ~/venv/arm64/3_9/appName/bin/activate && \
(PyInstaller) 2> pyinstaller_arm64.log && \
deactivate && \
rm -rf build appName.spec dist/appName && \
mv dist appName && \
hdiutil create -srcFolder appName appName_arm64.dmg && \
codesign -s "***" --timestamp -i "org.appName.appName" appName_arm64.dmg && \
xcrun notarytool submit appName_arm64.dmg --keychain-profile "org.appName.appName" --wait > notarytool_arm64.log && \
xcrun stapler staple appName_arm64.dmg > stapler_arm64.log

Terminal 2 (sometimes raises the error notarytool: No Keychain password item found for profile. Almost always works on 2nd try, if the 1st fails):

arch -x86_64 zsh

mkdir x86_64 && \
cd x86_64 && \
source ~/venv/x86_64/3_9/appName/bin/activate && \
(PyInstaller) 2> pyinstaller_x86_64.log && \
deactivate && \
rm -rf build appName.spec dist/appName && \
mv dist appName && \
hdiutil create -srcFolder appName appName_x86_64.dmg && \
codesign -s "***" --timestamp -i "org.appName.appName" appName_x86_64.dmg && \
xcrun notarytool submit appName_x86_64.dmg --keychain-profile "org.appName.appName" --wait > notarytool_x86_64.log && \
xcrun stapler staple appName_x86_64.dmg > stapler_x86_64.log

Does this:

arch -x86_64 zsh

mean that you’re running the entire chain under Rosetta?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Yes, because this way i make sure PyInstaller is making an x86_64 app (could also do this with a flag, but I prefer it this way. But actually maybe I should try it using the flag and not Rosetta. Did this especially for creating a venv so that pip installs the correct packages).

  • OK, I cannot run PyInstaller from my -x86_64 env successfully in an arm64 shell, so it looks like at least for this stepp I need Rosetta2.

Add a Comment