allow use of key fingerprints, because git secret tell/removeperson will match emails that contain desired email as substring, and other reasons

[joshrabinowitz]

As mentioned in #267:

if

• you are using keys where one user's email address is a substring of another's (for example [email protected] and [email protected]),

then

• using git secret tell [email protected] will add keys for both users and not just [email protected] (same with killperson and removing keys)

[joshrabinowitz]

update:

• https://www.gnupg.org/documentation/manuals/gnupg/Specify-a-User-ID.html says to use `<[email protected]'> (ie, with <>'s) to select keys
• but this doesn't work with keys generated with gpg --quick-generate-key [email protected], (edit: example fixed) because the email with those keys is stored without '<>'s (and many 'older' versions of gpg don't compensate for this).

[joshrabinowitz]

There is apparently a fix for this in recent versions of GnuPG, see https://dev.gnupg.org/T1927 from 2015. It is not likely to be backported to 2.0 because GnuPG 2.0 is EOL

[joshrabinowitz]

The only good solution I see for this is to keep track of emails->fingerprints ourselves in git-secret and use fingerprints as much as possible to specify keys when interacting with gpg

[nixpulvis]

I was about to open an issue titled something like "git-secret should use fingerprints". This is currently causing me some issues for me. Mainly it's impossible to remove a single duplicate key (email is the same) without asking the user to create a new key, or trial and error.

[joshrabinowitz]

@nixpulvis @sobolevn @simbo1905

Perhaps as a halfway measure we should allow users to specify keys by email or by fingerprint. Then when we check the email/fingerprint specified by the user, we first look for matching fingerprint. Only if we don't find a matching fingerprint do we fall back on the email matching logic.

Then eventually we can do exact email->fingerprint lookups in the code and use fingerprints everywhere possible in git-secret (which will fix this issue)

Input welcome!

[sobolevn]

Yes, we can fallback to emails if we fail to match keys by fingerprint. Looks like it should not break anything.

[simbo1905]

using the fingerprint of the public key seems like a good idea.

[joshrabinowitz]

As @ieugen points out in #512 , this also means if you have multiple keys with the same email address, you cannot specify which one with git-secret.

[ieugen]

I've also hit this issue. I have two keys with the same email and one of them is broken (git secret refuses to work with it)

When I git secret tell my@email both of them are added so I can't use git secret.

I believe the correct way to do it is to use fingerprints. Emails can be associated (likely) with multiple keys but key fingerprints / ids should not (very unlikely).

IMO this should be treated as a bug

[joshrabinowitz]

Hello, @ieugen

Thank you for your comment. We agree that this is a bug and we also agree with the suggestions you made in issue #512, to allow users to specify keys using using fingerprints and/or 'key ids'. As you also suggest in that issue report, these features are getting a little complex to solve in pure bash code.

Your problem above is similar to the one mentioned in #552. To work around your problem, could you remove the key that is 'broken' from your gpg keyring? (You could back up the contents using gpg's export functions if you want, then delete them using the --delete-keys and --delete-secret-keys options). Please let us know if this suggestion resolves your issue of having two keys with the same email address in your gpg keyring.

~We have plans to migrate git-secret from bash to rust, which will make it easier to add more complex features like this -- see https://github.com/sobolevn/git-secret-rust and #515. (If someone were to make a complete rewrite in another language though, we probably would not resist) We welcome help migrating git-secret to another language, which when feature complete, would be a drop-in, fully backward compatible replacement for the bash version of git-secret.~ Edit: this rewrite is unlikely to happen.

Again, please let us know if you can resolve your issue using gpg --delete-keys and --delete-secret-keys options.

[ieugen]

Hello @joshrabinowitz , I totally forgot about the other issue :D. I did just that - removed my old key and it all worked ok.

It's nice that you are using a custom keyring file. I think the operations could be done directly on that, even if git-secret does not do the right thing. Maybe it should be advertised a bit better. It's a feature IMO.

I salute your decision to move away from bash to a more modern programming language with some tooling to write tests and stuff.

I'm not familiar with Rust. I'm more of a Java / JavaScript user.

[joshrabinowitz]

Hello @ieugen,

1. You said:

It's nice that you are using a custom keyring file. I think the operations could be done directly on that, even if git-secret does not do the right thing

I don't understand what change you're asking for here.

By design, git-secret operates using two keyrings: the current user's keyring, (typically somewhere like ~/.gnupg/), and a second keyring in the repo, (which by default is stored in /your-repo/.gitsecret/keys).

git-secret uses gpg to access these two keyrings, so that each user with a public key in the /your-repo/.gitsecret/ keyring can hide and reveal files in a repo -- each user still has to have the right private key in their personal ~/.gnupg/ keyring. As you are illuminating, this should probably be explained better in the documents.

2. You also said:

Maybe it should be advertised a bit better. It's a feature IMO.

What changes do you think we should make to advertise / document this better? If you're so inclined, a PR is always welcome!

[ieugen]

Hi @joshrabinowitz ,

Point 1 does not require any changes. I was referring to the "bug" that git-secret has when it adds all keys for a particular email. This can be solved IMO by editing the repo keyring. The ability to edit the keyring is the thing to be advertised more IMO.

I hope what I said earlier did not come out the wrong way. I'm happy with how git-secret solves our problems. The issues IMO are with the implementation since bash is not the best tool to write and mainatain complex software.

[joshrabinowitz]

I don't think I misunderstood you or took your note the wrong way! Purely a technical discussion about what's the 'best' 'right' thing to do.

The bug in point 1) is actually a bug in gnupg which is hard to work around - see details above

Still not sure what you're asking with point 2). Yes, it's possible for users to directly manipulate the keychain in /repo/.gitsecret/keys using gnupg, but it's pretty much discouraged. What would we want to document differently?

3. Your point about bash is uncontested! The only counterpoint is that bash is so easy to deploy as opposed to most other languages, as we can count on bash existing on just about every system and don't need to build binaries (as we would using, say, C) for each target system. But yes, we're reaching the edge of what sort of features bash can easily support.

[joshrabinowitz]

I have a recommendation for implementation:

• Because of all the reasons described above, the idea is to internally always use fingerprints to describe keys.
• Also because of reasons described above, when the user specifies a key by email address, we avoid using gnupg to match the email to keys, and instead use our own code to match email address to keys.