Re: [PATCH] Add commit & tag signing/verification via SSH keys using ssh-keygen

[Fabian Stelzer <fs@gigacodes.de>]

> "Fabian Stelzer via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Fabian Stelzer <fs@gigacodes.de>
>>
>> set gpg.format = ssh and user.signingkey to a ssh public key string (like from an
>> authorized_keys file) and commits/tags can be signed using the private
>> key from your ssh-agent.
>>
>> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
>> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
>> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
>> verification.
> There are probably style and coding-guideline nit people will pick
> in the patch, but first of all I have to say that I am uncomfortably
> excited to see this addition.
>
> One thing that is unclear is how the 'allowed-signers' is expected
> to be maintained in the larger picture.  Who decides which keys
> (belong to whom) are trustworthy?  Does a contributor has to agree
> with the decision that certain keys are trustworthy made by somebody
> else in the project and use the same 'allowed-signers' collection of
> keys to effectively participate in the project?  How do revoking and
> rotating keys work?
>
> It was a deliberate design decision to let PGP infrastructure that
> is used to sign and verify signatures when we use PGP for signing
> without tying any of these decisions to the tracked contents, as
> that would reduce the attack surface for a malicious tree contents
> to affect the signing and verification (in other words, "we punted"
> ;-).  Even though I am not sure exactly what you meant by "defaults
> to .gitsigners", I am assuming that you meant a file with the name
> at the top-level of the working tree, which makes me worried, as it
> opens us to the risk of reading from and blindly trusting whatever
> somebody else placed in the tree contents immediately after we "git
> pull" (or "git clone").
>
> Thanks for working on it.
Glad to hear that :)
I tried to keep the style with the existing code but the IDE sometimes 
has its own idea.

I think there are two basic options for maintaining the allowed signers 
file:
1. Every developer has their own stored outside of the repo and 
adds/revokes trust manually like with gpg.
     A central repo would probably verify against a list managed by the 
tool (e.g. gitolite)
2. Store it in a .gitsigners file in the repo. This would only work if 
you only allow signed commits/pushes from this point onwards. But this 
way a shared understading of trusted users can be maintained easily.
     Only already trusted committers can add new users or change their 
own keys. The signers file is basically a ssh_authorized_keys file with 
an additional principal identifier added at the front like:
     fs@gigacodes.de ssh-rsa XXXKEYXXX Comment
     a@b.com ssh-ed25519 XXXKEYXXX Comment

Where are commits usually verified at the moment? On every devs checkout 
or only centrally on pushes?

The signers file also supports SSH CA keys and wildcard identifiers. At 
the moment i look up the principal dynamically via the public key so 
it's just a text info of who's key is it at the moment.
The SSH CA Stuff is probably a niche use case but could be cool in a 
corporate setting. Thats also what the revocation file is used for. The 
SSH CA can generate a KRL (like crl) which you put into it or you can 
specify explicit public keys in it to deny them.