Re: Updated Sourceware infrastructure plans

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Thu, 18 Apr 2024 at 00:28, Mark Wielaard wrote:
> We also encourage projects to use signed git commits where it makes
> sense. This can be done through the gitsigur process which supports
> hoos to only allow known (registered) signatures.
> https://inbox.sourceware.org/overseers/ZIz4NB%2FAqWpSNj5d@elastic.org/
> But can of course also be done in other ways. See this overview of how
> sigsigur, sigstore and b4 can provide a signed commit/release workflow:
> https://inbox.sourceware.org/overseers/ZJ3Tihvu6GbOb8%2FR@elastic.org/

Would it be possible for gitsigur to support signing commits with ssh
keys as well as gpg? Git supports this, and it's much easier for
everybody than having to set up gpg.

We already need an SSH key on sourceware.org to push to Git, so all
those public keys could be treated as trusted (via git config
gpg.ssh.allowedSignersFile). You could then sign your commits with the
same key that you use to push to sourceware.

Does requiring using a second, different key to sign commits really
add any value? If somebody has compromised my ssh key and can push to
sourceware, are we hoping that they won't have compromised my gpg key
as well?

I'm already signing my GCC commits that way, without needing to use
gpg or gitsigur:

commit 7c2a9dbcc2c1cb1563774068c59d5e09edc59f06 [r14-10008-g7c2a9dbcc2c1cb]
Good "git" signature for jwakely@redhat.com with RSA key
SHA256:8rFaYhDWn09c3vjsYIg2JE9aSpcxzTnCqajoKevrUUo
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Mar 21 23:09:14 2024