wk at gnupg.org
Tue Jul 27 19:44:24 CEST 2021
On Tue, 27 Jul 2021 11:15, Simon Josefsson said:
> However --locate-external-keys is a new command, and not even present in
> Debian buster. To solve the use-case of refreshing any expired local
Its Debian and they anyway had lots of changes on their own in it.
FWIW: The command is available since 2.2.17 (2019-07-09)
> gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon at josefsson.org
> How does GnuPG select which key is shown when running that command?
gpg merges the received key into a possible existing key. You may use
some "--import-options show-only" to avoid that. --locate-key does in
principle the same as if you woould do
gpg -er foo at example.org
and the key for foo at example.org does not exist.
> I reordered the keys in my exported file on the server, and now it looks
> like this:
Ah well, there should be only one key on the server. More are allowed
for key rollover, but we don't have useful maintanence tools for that.
> The server has my Ed25519 key first, but still GnuPG is showing my RSA
> key anyway.
The logic on how gpg considers what the best key to use is a bit
complicated. In case you want to look at it, start at
get_best_pubkey_byname. Note that logic kicks in only if you provide a
> Could the logic be to show the newest non-expired key?
That should be the case with --locate-key but not with
--locate-external-key becuase the latter does not look into the local
> Alternatively, show short summary output of all retrieved keys. That is
> probably the best?
Well, the idea was to have just one key and use that. What shall one do
if several keys for the same mail address are available and valid?
Encrypt to all these keys?
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the Gnupg-devel