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@xxxxxxxxxxxx> 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
