Re: Updated Sourceware infrastructure plans

Hi Jonathan,

On Fri, 2024-04-19 at 10:33 +0100, Jonathan Wakely wrote:
> 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%[email protected]/
> > 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%[email protected]/
> 
> 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.

O, nice, I didn't even know about this, while it has been available for
years: https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/

BTW. Note that the other way around is also possible, using your gpg
key as ssh key using gpg-agent --enable-ssh-support. See e.g.
https://gnu.wildebeest.org/blog/mjw/2019/02/17/new-pgp-key/

> 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 think it depends on the policy you use for signing commits.
Personally I only sign commits that correspond to a particular release.
But you can of course sign all commits with your ssh key at the same
time (I don't know if they mix though).

Cheers,

Mark