On Fri 2024-03-01 17:06:09 +0100, Ingo Klöcker wrote: > On Donnerstag, 29. Februar 2024 21:21:42 CET Daniel Kahn Gillmor wrote: >> human-readable names for certificates. But i don't see how to use that >> safely while dealing with GnuPG's risky implementation choices here. > > Allowing recipients to be specified by email address (or some other > part of a user ID) was inherited from PGP. And I guess it's part of > the reason for the success of PGP (and GnuPG) that one could specify > keys of recipients by email addresses instead of by hard to remember > key IDs (when those could still be considered unique) or by impossible > to remember fingerprints (or by file name as sequoia-pgp seems to > prefer).
I agree with you that it's nice to refer to people by human-memorable
names. I just wish it was safe to do so.
> Calling this a risky implementation choice of GnuPG is ridiculous.
Is it really ridiculous? It seems factual to me. Note that I'm not
saying GnuPG is the only one to make such an implementation choice, but
I really do think it's risky.
For example, GnuPG could instead offer an interface with explicit
options to allow the user to choose to match certificates by
fingerprint, or by e-mail address, or by name, or by full User ID, but
not a mishmash of all of the above.
> If anything then it's a risky implementation choice of pass to allow
> using anything other than a fingerprint in ~/.password-store/.gpg-id.
I agree, that's risky too! But as you say above (and as the message
that i sent, but which doesn't appear to have been delivered to the
list, also said), it's an understandable urge to want to use
human-readable names. It seems totally reasonable to put my own own
name there, for example! who knew that it could cause problems‽
Anyway, for `pass` to restrict the contents of .gpg-id to being a
fingerprint, the GnuPG API(?) requires `pass` to know exactly how to
match a fingerprint so that GnuPG also is also guaranteed to treat it as
a fingerprint. If a new version of GnuPG ever accepts other forms of
fingerprint, or requires a different form, then pass would need to be
updated to match the new expectations. That seems clumsy, and likely to
lead to upgrade friction down the line.
I agree with you that these kinds of tools should let the user do the
sort of things that users generally want to do. The tools should also
let them do those things safely by default, and without confusion.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
