Re: Updated Sourceware infrastructure plans
Jonathan Wakely <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha,gmane.comp.gcc.devel,gmane.comp.gnu.binutils,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAH6eHdSnMtHOdb2WCqR83Km5b_EmuM1Ni12oMjsXU_1u9GA7Nw@mail.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%[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. 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 [email protected] with RSA key SHA256:8rFaYhDWn09c3vjsYIg2JE9aSpcxzTnCqajoKevrUUo Author: Jonathan Wakely <[email protected]> Date: Thu Mar 21 23:09:14 2024