Message-ID: <CAO-hwJJY+sRiHX9KWqTAuR7Q8=3J8vu=FneusRago87uQYSxfw@mail.gmail.com>
Date:   Wed, 21 Sep 2022 12:17:04 +0200
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Josh Boyer <jwboyer@...nel.org>
Cc:     Linux Firmware <linux-firmware@...nel.org>,
        Juerg Haefliger <juerg.haefliger@...onical.com>,
        Peter Robinson <pbrobinson@...oraproject.org>,
        Takashi Iwai <tiwai@...e.com>, contact@...rentcarlier.com,
        mpagano@...too.org,
        "Limonciello, Mario" <Mario.Limonciello@....com>,
        Jared Dominguez <jaredz@...hat.com>,
        Alex Deucher <alexdeucher@...il.com>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: linux-firmware signed commits; does anyone care?

On Fri, Sep 16, 2022 at 3:33 PM Josh Boyer <jwboyer@...nel.org> 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".

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

Powered by blists - more mailing lists