On 11.08.21 03:12, Junio C Hamano wrote:> > * 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.
