Specify admin key when multiple are present

[ausmith]

Today when one does blackbox_addadmin you can only specify the email of the user you wish to add (NOTE: see comment 1 about using a key id instead of an email address). It would be valuable to be able to specify which of the available keys to use to avoid 2 possible scenarios:

1. A user has somehow lost access to one of their keys, or worse it was compromised, and encrypting with the old key is no longer desired.
2. Multiple keys were uploaded for a service account (we maintain keys for our CI/CD system to decrypt our secrets during automated deployments) but only one of the keys are available to that user.

A scenario to prove option 2 can be an issue: with 3 keys for a single user, encrypt a blackbox file with all 3 keys, and then try to decrypt the file with only the private key of the middle of the 3 keys used to encrypt the file. The result is the message gpg: decryption failed: secret key not available as it attempts to decode with one of the other 2 keys not present on the system (have not verified if the first or last key is being attempted).

How to reproduce (using 3 "machines" to isolate GPG environments, could also use containers or VMs):

• Machine 1: Create a fake user with 3 keys ([email protected] for the sake of this example, please use a different email...)
• Machine 1: Upload all 3 separately to a public key server, preferably in such a way that you can easily tell them apart by date stamps (our user in question had keys uploaded on 2016-12-11, 2016-12-13, and 2017-2-14)
• Machine 2: Encrypt a file using blackbox with this fake user (e.g. blackbox_addadmin [email protected]; blackbox_update_all_files)
• Machine 2: Verify multiple entries for [email protected] appear when using blackbox_cat on one of the newly encrypted files
• Machine 3: Use private key number 2 from the 3 key pairs created to try and decrypt the files in this repo

If we could specify an identifying hash with the blackbox_addadmin command like blackbox_addadmin [email protected]#1234567890ABCDEF then this issue could be avoided with specificity. Added benefit would be the ability to use specific user sub keys that are under a single email address (example scenario: team 1 and team 2 both accidentally use [email protected] as the user for their GPG keys and now can create independent keys without collision).

[ausmith]

It was pointed out to me that a key id could be used instead of an email address, however using this method one has only key ids to work with when auditing admins (example: each key id must be looked up when auditing a repo's blackbox admins). Will edit this into the original issue.

[mbreitung]

This issue has burned us in the past. Specifying a hash instead of the email "works", but is then not maintainable. Then I need to map that hash back to a real user somewhere.

[gwengullett]

My team has found a workaround for now with this issue. We are putting the key ID in the admin file, and putting a comment on the same line with the user email.

Example:

ABC12345 # [email protected]

All of my team members have confirmed that they are able to still successfully decrypt secrets after this change over.

However, support in the CLI for this case would be amazingly helpful and more intuitive.

[ifeltsweet]

How about adding a comment to your key when you generate one and then using full UID like so:

John Doe (Home PC) <[email protected]>
John Doe (MacBook Pro) <[email protected]>

This seems to work, however users must remember to specify unique key comment in case they have multiple keys under same name and email. In comparison, @eclipsenet method is fool-proof from get go.

UPDATE: tested the above assumption, and no, it does not work, blackbox doesn't handle spaces in the key name and so assumes the key name to be up to the first space.

[mook-as]

Attached patch to blackbox_addadmin will fetch the given key (if not already known), and use the fingerprint # [email protected] format in blackbox-admins.txt (using the full fingerprint because why not). However, I'm not sure that's robust enough for what blackbox supports (it's only been tested on Linux, for example, and I'm not sure I'm getting information out of GPG correctly).