Re: linux-firmware signed commits; does anyone care?

[Limonciello, Mario]

On 9/21/2022 05:17, Benjamin Tissoires wrote:
> On Fri, Sep 16, 2022 at 3:33 PM Josh Boyer <jwboyer@xxxxxxxxxx> wrote:
> > 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.
>
> People already are saying that they do not see value in GPG signed
> commits, but I'd like to add a few bits here.
>
> As Josh said, the idea is that we modernize the workflow for
> linux-firmware by automating what can be automated.
> The first thing that seems to be possible is automatically merge
> submitted MR assuming:
> - the general CI tests are passing (Mario already has a few sanity ones)
> - the commits do not touch WHENCE (so we have a reference on who is
> responsible for what)
> - the commits are signed by the maintainer of that said blobs (which
> would be matched against the WHENCE file)
>
> The idea is that if a maintainers of a blob submits a commit and signs
> it, there is no real reason to not merge it ASAP, given that we can
> always say: "well, it's the fault of X who is responsible of this file
> and who signed it, so we know it's actually X".

But as a counter-point, you can accomplish a similar-ish outcome just by 
the fact of using Gitlab.  If you're using Gitlab, all the blobs will 
tie back to a Gitlab user ID.

IDs can be added to an allow list of contributors that are allowed to 
merge directly.

You have the possibility to worry about someone's Gitlab login ID being 
compromised, but that could be mitigated by requiring everyone on Gitlab 
to use 2FA to interact with the project.

That at least to me feels like a good proxy of proving someone's 
identity without the pain of GPG signing, verifying GPG, and the 
logistics of the bot.

> Then comes the question of maintainers signing commits. If we ask
> submitters to sign their commits to have a fast track, it makes IMO
> sense to also ask the maintainers to sign their commits to show the
> way it is supposed to be done. I wouldn't care much about the
> automated bot that would merge the commit. If we need to have it sign
> the merge commit, we can do it, and this will only give the
> information that the process was followed.
>
> > 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.
>
> TBH, do we ever need to validate signed commits besides in the CI case
> or if something wrong happens?
>
> To make a parallel, Linus requires people to sign their PR, but he
> doesn't need to sign his commits. Because whatever goes into his tree
> is from him, obviously him. However, he requires maintainers to send
> signed PR to ensure this is coming from a trusted source. So he is the
> only one caring for signed PR, and we just trust him.
>
> So in our case, if signing for maintainers is not too much of a pain I
> would say:
> - to automate inclusion of blobs, we should ask vendors to sign their commits
> - to show the way, maintainers should still sign their commits (even
> if no one cares)
> - the CI should verify who signed what and if the signature is valid
> - end users only care about the signed tarball, that they trust the
> maintainers will build from a tree that is trusted
>
> OTOH, dropping the signing of the merge commit from the maintainers
> would allow them to just hit the merge button in the UI, which might
> be a simpler thing than having to forward that MR to a bot.
>
> > 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?
>
> I hope I didn't add too much confusion :)
>
> Cheers,
> Benjamin