notarytool: No Keychain password item found for profile

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.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!

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 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"

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"