"Fabian Stelzer via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
From: Fabian Stelzer <fs@xxxxxxxxxxxx>
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@xxxxxxxxxxxx ssh-rsa XXXKEYXXX Comment
a@xxxxx 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.
