Re: What's cooking in git.git (Aug 2021, #04; Tue, 10)

From: Fabian Stelzer <fs@gigacodes.de>
Date: Aug 11, 2021, 07:22 UTC
Message-ID: <503f6c75-5b1b-c6aa-3d21-1abef887a689@gigacodes.de>
In-Reply-To: <xmqqh7fwbx86.fsf@gitster.g>

On 11.08.21 03:12, Junio C Hamano wrote:>

Show 15 quoted lines

> * fs/ssh-signing (2021-08-03) 9 commits
>  - ssh signing: test that gpg fails for unkown keys
>  - ssh signing: tests for logs, tags & push certs
>  - ssh signing: duplicate t7510 tests for commits
>  - ssh signing: verify signatures using ssh-keygen
>  - ssh signing: provide a textual signing_key_id
>  - ssh signing: retrieve a default key from ssh-agent
>  - ssh signing: add ssh key format and signing code
>  - ssh signing: add test prereqs
>  - ssh signing: preliminary refactoring and clean-up
> 
>  Use ssh public crypto for object and push-cert signing.
> 
>  Comments?
>

Anything i can do to help this along? I don't think there are any more open review issues but i'm of course open to new ones ;) I do have a minimal change (initially i used git_config_string instead of _pathname for the allowedSigners and revocation files) that i could submit in a new version to bump it up but not really anything else.

I do have a few follow up todos that i'd like to start working on. But i'm not sure if thats a good idea when the base functionality might still change.

My roadmap for this feature:
 - check/fix usage of gpg-interface:check_signature. some call sites
currently ignore its exit code and unconditionally dereference signature
check results :/ - This could probably be done right now.

 - rename "gpg." options (sign. ?) and make documentation clear that
signing is no longer limited to gpg. (backwards compatible of course)

 - rename gpg-interface (signing.h|c ?) and at least some of its api
code to be less gpg specific to make developers aware that this code not
only deals with gpg anymore

 - implement ssh's new verify-time so we can verify commits in the past.
With git i only need to trust the key up to the commit timestamp. Unless
its is revoked specifically i don't mind if it expires and i don't want
to invalidate a developers commits just because they change their key.
The old commit should still verify. This is not really possible with gpg
unless people renew/extend and then distribute their existing keys.

 - Add a config option to fix the ssh signing principal to the
committers email address instead of looking it up by the signatures
public key (this is required for the next feature)

 - Allow "Trust on first use". Corporate environments and forges can
easily roll their own allowedSigners file based on the user data they
already have (and even distribute this file to their users). Other
workflows (email based patches) make this file much harder to maintain.
If we use the committers email as principal to look up their key we can
add it automatically, or ask the user similar to a first ssh connection
if we should add it to our local allowedSigners file if not found. Only
a change of keys is a problematic operation and needs to be monitored /
verified manually (not sure how we would handle this yet). Something
like this was already suggested here: https://lwn.net/Articles/803619/

 - add patch signing & verification to format-patch & am. Since ssh
signatures are rather small we could probably append them to the patches
somehow. This needs some planning since it's probably easy to break
peoples scripts/workflows if not careful.