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

[Junio C Hamano <gitster@pobox.com>]

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