RE: [PATCH v6 5/9] ssh signing: parse ssh-keygen output and verify signatures

["Randall S. Becker" <rsbecker@nexbridge.com>]

On July 30, 2021 10:32 AM, Fabian Stelzer wrote:
>On 30.07.21 16:26, Randall S. Becker wrote:
>> On July 30, 2021 4:17 AM, Fabian Stelzer wrote:
>>> Subject: Re: [PATCH v6 5/9] ssh signing: parse ssh-keygen output and
>>> verify signatures
>>>
>>> On 30.07.21 00:28, Randall S. Becker wrote:
>>>> On July 29, 2021 5:29 PM, Fabian Stelzer wrote:
>>>>> On 29.07.21 23:25, Randall S. Becker wrote:
>>>>>> On July 29, 2021 5:13 PM, Fabian Stelzer wrote:
>>>>>>> Subject: Re: [PATCH v6 5/9] ssh signing: parse ssh-keygen output
>>>>>>> and verify signatures
>>>>>>>
>>>>>>> On 29.07.21 23:01, Randall S. Becker wrote:
>>>>>>>> On July 29, 2021 4:46 PM, Junio wrote:
>>>>>>>>> Fabian Stelzer <fs@gigacodes.de> writes:
>>>>>>>>>
>>>>>>>>>> On 29.07.21 01:04, Jonathan Tan wrote:
>>>>>>>>>>
>>>>>>>>>>> Also, is this output documented to be stable even across locales?
>>>>>>>>>> Not really :/ (it currently is not locale specific)
>>>>>>>>>
>>>>>>>>> We probably want to defeat l10n of the message by spawning it in the C locale regardless.
>>>>>>>>>
>>>>>>>>>> The documentation states to only check the commands exit code.
>>>>>>>>>> Do we trust the exit code enough to rely on it for verification?
>>>>>>>>>
>>>>>>>>> Is the exit code sufficient to learn who signed it?  Without
>>>>>>>>> knowing that, we cannot see if the principal is in or not in
>>>>>>>>> our
>>>>>>>> keychain, no?
>>>>>>>>
>>>>>>>> Have we not had issues in the past depending on exit code? I'm not sure this can be made entirely portable.
>>>>>>>>
>>>>>>>
>>>>>>> To find the principal (who signed it) we don't have to parse the output.
>>>>>>> Since verification is first a call to look up the principals
>>>>>>> matching the signatures public key from the allowedSignersFile
>>>>>>> and then trying verification with each one we already know which
>>>>>>> one matched (usually there is only one. I think multiples is only
>>>>>>> possible with an SSH
>>>>> CA).
>>>>>>> Of course this even more relies on the exit code of ssh-keygen.
>>>>>>>
>>>>>>> Not sure which is more portable and reliable. Parsing the textual output or the exit code. At the moment my patch does both.
>>>>>>
>>>>>> What about a configurable exit code for this? See the comment below about that.
>>>>>>
>>>>>
>>>>> I'm not sure what you mean. Something like "treat exit(123) as success"?
>>>>
>>>> How about gpg.ssh.successExit=123 or something like that.
>>>>
>>>
>>> I don't quite understand what the benefit would be. Do you have any
>>> specific portability problems/concerns where the ssh-keygen format is different or exit codes differ?
>>> I think using a script that provides exit(0) on success and the
>>> correct output to wrap ssh-keygen and setting it in gpg.ssh.command can already cover edge cases when needed.
>>>
>>>>
>>>> Is there documentation on the possible arguments the patch series
>>>> will use for this so one can create a wrapper script? I had to look
>>>> into
>>> the code to find out what GIT_SSH_COMMAND actually required when the ssh variant was "ssh". I'd rather not have to do that in this
>case.
>>>>
>>>
>>> The documentation in ssh-keygen(1) is quite good and straight forward
>>> for verification and signing. Again if you have any specific portability concerns i'd be glad to help.
>>
>> I do know the ssh-keygen interface and that does not really answer my doubts.
>>
>> My point here is that ssh-keygen is not always available in the same form on all platforms. Providing a full emulation of all arguments is
>not effective or likely even possible, and a waste of time. I'm asking for documentation on what specific options you are using for each
>function. OpenSSL is not available everywhere, and even where it is, the latest versions are not always available. It is important to know
>what the specific interface is being used.
>>
>>
>
>Fair enough. Where would you expect to look for such documentation?
>I'm not sure sth like config/gpg.txt is the right place for this.

My suggestion is wherever gpg.ssh.command is documented. So really, I think config/gpg.txt is the place. It's that or we create some common location for compatibility layer documentation (what I would really prefer). If there is a good place to put that, I might be willing to take on the documentation task, but my $DAYJOB is keeping me from anything heavy at this point.

With my thanks,
Randall