Messages in this thread | | | Date | Wed, 21 Sep 2022 10:44:34 +0200 | From | Juerg Haefliger <> | Subject | Re: linux-firmware signed commits; does anyone care? |
| |
I don't care much about GPG signed commits so dropping them is fine by me.
...Juerg
> Some time ago, we went back to doing ~monthly releases for > linux-firmware primarily to help distributions package firmware in a > simpler manner. We GPG sign the tarballs, as is good practice, but as > part of reintroducing the tarballs we also started having a > linux-firmware maintainer GPG sign *every* commit done by a > maintainer. The intention there was that because we're dealing with > binary blobs we really have no recourse to see changes unlike a source > code repo. The signed commits at least provides a measure for > interested people to ensure the repo itself is only being committed to > by a recognized maintainer and it isn't compromised (in theory). The > downside is that pull requests are merged non-ff and we wind up > signing the merge commit. > > The question at hand though, is does anyone care about the GPG signed > commits? It's not clear to me this practice is even noticed nor if it > is bringing any value to this project. Since we've started this > practice, I am literally the only one committing to the repo and while > it isn't hard to do I want to know if it's actually useful to anyone. > > I ask for two separate reasons. The first is that a group of > interested firmware submitters is looking at modernizing the workflow > for the linux-firmware project and moving to a merge request workflow > instead of submitting giant binary blob patches via email. This would > allow us to put some CI in place for simple checks to the WHENCE file, > etc. Doing this while still having GPG signed commits isn't > impossible but it certainly complicates things a bit, and would likely > require a trusted bot to sign commits. That has implications on > secret storage and changes the dynamic on trust levels that make the > whole thing even more questionable. > > The second reason is that even if people are validating the GPG signed > commits, it's not exactly user friendly. I've been looking at > sigstore and recor and that might be a better solution in the long run > if we do want to utilize something like the current scheme. > > I'll still GPG sign the tarballs, but I'd like to propose dropping our > current self-imposed requirement that all commits are GPG signed. > Thoughts? > > josh
[unhandled content-type:application/pgp-signature] | |