Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys

[Fabian Stelzer <fs@gigacodes.de>]

On 01.06.2022 00:05, Junio C Hamano wrote:
>Fabian Stelzer <fs@gigacodes.de> writes:
>
>>>Thanks for replying, Fabian.
>>>
>>>My main issue is that ecdsa-sha2-* keys currently seem incompatible
>>>with `gpg.ssh.defaultKeyCommand = "ssh-add -L"`
>>>
>>>The git-config documentation of `gpg.ssh.defaultKeyCommand` says:
>>>
>>>> To automatically use the first available key from your ssh-agent set this to "ssh-add -L".
>
>This is puzzling.  One chooses the key to use when signing, and the
>key should go to the gpg.ssh.defaultkey, and also "ssh-add" is told
>about the key for convenient access.

I think you mean `user.siningKey` but yes, this is the best way to do this.

> Asking "ssh-add -L" about the
>keys it knows about and randomly pick the first one it happens to
>tell you about sounds totally backwards to me.
>
>I may have a key I use to sign, and one key each to go to various
>destinations, all of which "ssh-add -L" may know about.  It alone
>cannot fundamentally tell because it does not know what you intend
>to use each key for.
>
>Of course, as your own custom script, defaultKeyCommand may know
>which keys you intend to use for connecting and which keys you
>intend to use for signing.  It may even need to know which key you
>intend to use for each project you work with and your .git/config
>may have something to tell the script what "trait" the key to be
>used that appear in "ssh-add -L" output should have (perhaps the key
>is rotated very often so you cannot write the exact key in your
>configuration, but perhaps the comment at the end of each line have
>sufficient cue to tell them apart).  So, the custom script would
>need to go line by line to find the key to use in the first place,
>and if it is computationally capable enough to do so, it should be
>easy to prefix key:: in front.  IIRC, we designed the system in such
>a way that it is not an error to prefix key:: in front of ssh-* keys.
>
>In any case, perhaps we should extend the documentation a bit.  It
>generally is not sensible to just use "ssh-add -L" and pick one
>random key out of it, so we shouldn't be encouraging such a use, I
>suspect.

Yes, I think that reasonable. The script can do some advanced decision 
making / key lookup if needed. The use-case for me was to enforce/encourage 
use of the correct users keys on a shared development server in a corporate 
environment (i have a global directory of all the users keys and want to 
make sure everyone uses their correct one when signing).

I'll take a look at the docs and suggest a patch in a bit.