On Wed, Jun 8, 2022 at 11:24 AM Fabian Stelzer <fs@xxxxxxxxxxxx> wrote: > > Using `ssh-add -L` for gpg.ssh.defaultKeyCommand is not a good > recommendation. It might switch keys depending on the order of known > keys and it only supports ssh-* and no ecdsa or other keys. > Clarify that we expect a literal key prefixed by `key::`, give valid > example use cases and refer to `user.signingKey` as the preferred > option. > > Signed-off-by: Fabian Stelzer <fs@xxxxxxxxxxxx> > --- > Documentation/config/gpg.txt | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt > index 86892ada77..86f6308c4c 100644 > --- a/Documentation/config/gpg.txt > +++ b/Documentation/config/gpg.txt > @@ -36,9 +36,12 @@ gpg.minTrustLevel:: > > gpg.ssh.defaultKeyCommand:: > This command that will be run when user.signingkey is not set and a ssh > - signature is requested. On successful exit a valid ssh public key is > - expected in the first line of its output. To automatically use the first > - available key from your ssh-agent set this to "ssh-add -L". > + signature is requested. On successful exit a valid ssh public key > + prefixed with `key::` is expected in the first line of its output. > + This allows for a script doing a dynamic lookup of the correct public > + key when it is impractical to statically configure `user.signingKey`. > + For example when keys or SSH Certificates are rotated frequently or > + selection of the right key depends on external factors unknown to git. > > gpg.ssh.allowedSignersFile:: > A file containing ssh public keys which you are willing to trust. > -- > 2.35.3 > Nice. This makes sense to me.
