Warning messages when configuring keychain

[cowwoc]

I get this output when running the script. If it's harmless, please modify the script to avoid the warnings (e.g. check if a file exists before running chmod on it). If the warnings are not harmless, let's debug them further.

API token for builds: ABC
security: SecKeychainCreate login.keychain: A keychain with the same name already exists.
/dev/fd/63: line 261: /Users/builds/Library/Keychains/.keychain_pass: Permission denied
chmod: /Users/builds/Library/Keychains/.keychain_pass: No such file or directory

[cowwoc]

Line 261 is invoking sudo echo which doesn't work as expected. See http://stackoverflow.com/q/84882/14731

I will create a pull request soon to fix this.

[cowwoc]

I left the warning message for A keychain with the same name already exists because I didn't want to suppress other warnings the command might output.

[cowwoc]

Okay, we have the following outstanding warning messages:

1. security: SecKeychainCreate login.keychain: A keychain with the same name already exists. triggered by sudo -i -u ${SERVICE_USER} security create-keychain -p ${OSX_KEYCHAIN_PASS} ${OSX_KEYCHAIN}
2. security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain. triggered by KEYSTORE_PASS=sudo -i -u ${SERVICE_USER} ${SERVICE_HOME}/security.sh get-password --account=${SERVICE_USER} --service=java_truststore``
3. Security wants to use the "Local Items" keychain. dialog box triggered by sudo -i -u ${SERVICE_USER} ${SERVICE_HOME}/security.sh set-password --password=${KEYSTORE_PASS} --account=${SERVICE_USER} --service=java_truststore

I'm going to try again to prevent these warning messages, and especially to prevent the pop up triggered by step 3.

[cowwoc]

I fixed number 1 and 2 but I'm stuck on number 3. It seems "Local Items" was introduced in Mavericks and it cannot be removed or configured: http://apple.stackexchange.com/a/107078

I see the code executing sudo -i -u builds security add-generic-password -U -w ky2lMNs-Jm0L-rfQEVbG -a builds -s java_truststore login.keychain where ${SERVICE_USER} is builds. For some reason, executing this line causes the dialog box (mentioned in number 3) to pop up and it requires me to enter the password of the user running the installer, instead of that belonging to SERVICE_USER. Can you please investigate this on your end?

[cowwoc]

I found the culprit!

security.sh always locks the keychain on exit. It turns out that executing sudo -i -u builds security lock-keychain login.keychain locks the local user's Local Items keychain instead of (or maybe in addition to) that of the Jenkins user. I don't know whether this is a bug or a "feature" on Apple's part.

I propose we stop automatically locking and unlocking the keychain in security.sh and let the calling script explicitly request these operations. If/when Apple fixes this bug, we can always put back this feature.

How would you like to proceed?

[rhwood]

I am not willing to leave an unlocked keychain available to an externally controlled service, and your proposed changes do that.

Note that you are attempting to work around issues in the installer alone by modifying the service itself.

[cowwoc]

The problem is that I can't have security.sh lock the keychain because I have no way of unlocking it again. Meaning, I have SERVICE_USER's keychain password (to unlock it) but not that of the local user.

There are only 2 ways I can think of resolving this problem:

1. Not implicitly locking the keychain after each operation (which is what I'm doing).
2. Asking the local user for their keychain password even though I shouldn't really need it.

I felt that #1 is a better solution. We could always lock the keychain at the end of the installer script. I did not out of fear that if someone runs the installer twice, the second time will fail.

What do you propose we do instead?

[cowwoc]

@rhwood I'm still waiting for your response :)

Locking someone else's keychain also locks your own keychain. To prove this run the following test:

1. Open Keychain Access
2. Open a Terminal.
3. In the Terminal, run sudo -i -u <username> security lock-keychain login.keychain, where <username> is a second account. Notice (using Keychain Access) that this operation locks your keychain as well.

There is no security risk in leaving the keychain unlocked because it gets locked automatically when sudo ends. To prove this, run the following test:

1. Open a Terminal.
2. In the Terminal, run sudo -i -u <username> security unlock-keychain login.keychain, where <username> is a second account.
3. Repeat step 2 a second time. Notice that you get prompted for the password a second time. If the keychain was really unlocked, it wouldn't prompt you again.