> Am 16.09.2024 um 14:45 schrieb Jonathan Wakely <jwak...@redhat.com>:
>
> 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.
I think that particular hole could be closed by verifying the commit on the
server. At least committer should match the SSH key account owner (we’d have
to allow some or a configured identity of course, not just x...@gcc.gnu.org).
The author can be different when pushing for somebody else.
I was thinking that if my SSH key is compromised signing the commit with it
doesn’t help. Signing with a GPG key on the other hand would mean we have a
second factor.
Richard
> 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
>
