"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.
