Codesign says "no identity found" however the identity is on the keychain

Question

I am integrating code signing into our builds and have created a custom keychain which is held within the source code tree and used to sign the code (it's copied to ~/Library/Keychains before being used, so it's in a well known location).

However when attempting to sign I get an error:

$ /usr/bin/codesign --sign='Mac Developer: John Doe (AA1AAA1AAA)' \
    --keychain=~/Library/Keychains/xxx.keychain \
    dist/64/gmake/release/bin/libmylib.dylib

Mac Developer: John Doe (AA1AAA1AAA): no identity found

However:

$ security find-identity -p codesigning ~/Library/Keychains/xxx.keychain

Policy: Code Signing
  Matching identities
  1) 49F2FBE79899DF18A9638AC6B1302E2EB6E079AD "Mac Developer: John Doe (AA1AAA1AAA)"
     1 identities found

  Valid identities only
  1) 49F2FBE79899DF18A9638AC6B1302E2EB6E079AD "Mac Developer: John Doe (AA1AAA1AAA)"

So I don't understand why codesign is unable to find the identity.

Can anyone suggest a solution?

Note that I have also tried with the identity's SHA-1, with the same result.

Sabrinasabsay

Answer 1

Some of codesign's error messages are less than clear. The problem here is that codesign couldn't find the keychain, and that is caused by the use of --keychain=~/path. This is interpreted as a single argument and no tilde expansion is performed. If you modify your command to use separate arguments it should work as expected:

codesign --sign 'Mac Developer: John Doe (AA1AAA1AAA)' \
    --keychain ~/Library/Keychains/xxx.keychain \
    dist/64/gmake/release/bin/libmylib.dylib

Inhumation

Interesting; I didn't consider that the shell wouldn't expand ~ if I specify the arguments in this way. I will test tomorrow and get back to you, however I think you are onto a winner. – Sabrinasabsay

Yes, this is the answer, however I am now getting "User interaction is not allowed" despite the fact that I've unlocked it with security unlock-keychain. Now I know that sequence will work with login.keychain (I do it often) however it doesn't appear to work when using a non-standard keychain. I hate to be a help vampire but do you have any suggestions? – Sabrinasabsay

I can think of a couple possibilities. One is that the keychain has not been configured to always allow codesign access to the private key so the system wants to prompt the user to allow access. You can set that up via Keychain Access by double-clicking the private key and adding codesign under access control (or allow all apps). The other is that the default keychain unlock timeout of 5 minutes is too short if unlocking occurs early in the build process. You can control this via keychain settings to either extend or remove the timeout. – Inhumation