Hi there! The README asks for an issue to be submitted if we solve the issue of macOS Keychain requiring manual approval while running gon. Here's how we solved it at Anchore.
In order for a keychain item (e.g. the code signing key) to be accessed immediately without prompting the user, you need to set a "partition list" for the keychain item. According to man security (for the subcommand set-key-partition-list):
[...] The "partition list" is an extra parameter in the ACL which limits access to the key based on an application's code signature. You must present the keychain's password to change a partition list. If you'd like to run /usr/bin/codesign with the key, "apple:" must be an element of the partition list.
So, if users run security set-key-partition-list ... prior to running gon, gon/codesign can use the signing key immediately without requiring a human's approval.
There's an important catch:
You must present the keychain's password to change a partition list.
We found that most CI tools with macOS environments don't give you the password to the running user's default keychain.
We solved this by creating a brand new keychain on the fly, for the sake of being in control of the keychain's password the whole time. This keychain can be totally ephemeral, and its password can be randomly generated at the last minute.
Hope this helps. Let me know if you have any questions.
Hi there! The README asks for an issue to be submitted if we solve the issue of macOS Keychain requiring manual approval while running
gon. Here's how we solved it at Anchore.In order for a keychain item (e.g. the code signing key) to be accessed immediately without prompting the user, you need to set a "partition list" for the keychain item. According to
man security(for the subcommandset-key-partition-list):So, if users run
security set-key-partition-list ...prior to runninggon, gon/codesign can use the signing key immediately without requiring a human's approval.There's an important catch:
We found that most CI tools with macOS environments don't give you the password to the running user's default keychain.
We solved this by creating a brand new keychain on the fly, for the sake of being in control of the keychain's password the whole time. This keychain can be totally ephemeral, and its password can be randomly generated at the last minute.
Hope this helps. Let me know if you have any questions.