On Mon, 16 Sept 2024 at 13:13, Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Mon, Sep 16, 2024 at 1:37 PM Jonathan Wakely via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > Git supports signing commits with a GPG key, and more recently (since
> > Git 2.34) also started supporting signing with an SSH key. The latter
> > is IMHO much easier to set up, because anybody who can push to the GCC
> > repo already has an SSH key configured.
> >
> > To start signing your git commits, just enable commit.gpgsign (which
> > also enables signing with SSH, despite the name) and tell Git where to
> > find your public key. To use SSH keys instead of GPG, set
> > gpg.format=ssh. I suggest the ssh key you sign with should be the same
> > key that you use to push to gcc.gnu.org / sourceware.org
> >
> > i.e.
> >
> > git config --global gpg.format ssh
> > git config user.signingKey ~/.ssh/id_your_gcc_key.pub
> > git config commit.gpgsign true
> >
> > More info online e.g.
> > https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html
>
> What is the benefit of having a SSH signature in addition to
> sourceware verifying
> the SSA key upon commit?
Great question! Most of the time they're the same person and the same
key, so the benefits aren't obvious.
One benefit is that the signature on the commit is recorded in the
repo itself, and can be inspected later. The SSH key used to do the
push is only used to authenticate your user to the server, but once
you're authenticated what goes into the repo is not associated with
that key. And I can authenticate to the server with my key, and then
push commits that "forge" your authorship, but setting my git config
user.email and user.name to pretend to be you.
My SSH key would let me push, but nothing verifies that the Author and
Committer fields match my "real" name, or match the SSH key's owner
(Git has to allow it so that people with write access to push patches
for people without write access). But if you routinely sign all your
own commits, then if I try to impersonate you the "forged" commit
wouldn't be signed by your key. Maybe not a big concern, because we
trust our committers to not do dumb or malicious things. But if
somebody does manage to compromise a sourceware account, they could
push something to our repo that has your name on it, and maybe people
wouldn't notice a problem ("oh, this commit was by Richi, I won't
check every line because I trust him to do good work and he knows what
he's doing"). If the commit isn't signed, and your other commits are
signed, that would be a red flag. Is this protecting against a real
threat? I dunno, but since it's easy to configure the signing once and
then forget about it, I decided to enable it as an extra layer of
integrity that takes no effort.
N.B. Frank also raised the topic of signing (and checking) last year:
https://sourceware.org/pipermail/overseers/2023q2/019288.html
