From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F384C3858404; Tue, 27 Sep 2022 20:10:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F384C3858404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1664309435; bh=BUw+2WaQzYLG3e833lFWtnTAySEJcpuyQigCbsKpPoU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xjdxmk2U7/s3HWrXVv0faFTjdIQvkIixsAoWTpf1OC2mDeNAwZeApEf/wE2nNjSMu XMIZE9Cyow7pNmZhF190MjFJXxP2N+jnDNUhIYNTiOJUiqYKUcI+1pbpz7K5GABAoQ KkrIzBHcPhuISGp+JolLKcAaiLuV1bDP5oslmASE= From: "mark at klomp dot org" To: overseers@sourceware.org Subject: [Bug Infrastructure/29615] prototype & document SOP for signed-git-op repo Date: Tue, 27 Sep 2022 20:10:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: sourceware X-Bugzilla-Component: Infrastructure X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: overseers at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29615 --- Comment #6 from Mark Wielaard --- (In reply to Serhei Makarov from comment #5) > One issue with the SLSA4 checklist is that SLSA4 seems to be written in a > way that assumes developers are reviewing pull requests and there's a mag= ic > forge that everyone trusts to securely decide when the merge criteria have > been met. Applying it to individual commits on a mailing-list workflow wi= ll > be tricky and AFAIK the kernel isn't currently doing that. The example on > SLSA4 website of a compliant project is SUSE Open Build System, which sou= nds > magic-forge-y. Yes, I think it is mostly used for "downstream" (distro like) projects where the upstream (signed) release tarball is used as trusted input and then any patches on top of that are treated at SLSA4 level. But I don't think the point is to adopt all SLSA level 4, but to see how fa= r a project could get if it tried. > (Just trying to wrap my head around how it would hypothetically look. In > fully-paranoid SLSA4, we would need to verify >=20 > (a) the patch series submitted to the mailing list was reviewed & signed = off > by > (b) the patch series committed to the Git repo matches exactly what was > signed off in the mailing list (no last-minute good-Samaritan fixup by the > maintainer) >=20 > and all of that would need to be recorded by GPG signatures on the mailing > list archives* and in the Git repo and verifiable by anyone after the fac= t, > not 'oh, we has a forge website, and the forge's security widget ok'ed the > merge, so the resulting Git repo must be good; hope no one hacked the for= ge'. >=20 > [*On an 8-patch series, 2 reviewers would need to attach a total of 16 GPG > signatures. Maybe with suitable tooling you could batch up the contents of > the 8 patches into 1 email, and sign that, I dunno. {Forget doing that in > your corporate GMail web client.} You would then have a script anyone can > run for auditing purposes that slurps the Git repo and mailing list archi= ves > and flags any commits that don't have two matching, GPG-signed > Signed-Off-By: replies by reviewers.] So there are different ways to attest a patch or email is valid. Using a public-inbox instance like https://inbox.sourceware.org/ you can us= e b4 for patch attestation using dkim, gpg-signed emails or patatt. See https://gnu.wildebeest.org/~mark/sourceware/presentation.html#slide14 https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation https://people.kernel.org/monsieuricon/end-to-end-patch-attestation-with-pa= tatt-and-b4 Also tools like git-pw or b4 make it easy to collect all commit/patch emails and create a new patch that has all Signed-Off-by/Reviewed-by/... signoffs. The idea is not to carry-over all signatures on the individual email messag= es, but to trust the final committer to have verified them all. And only added = the signoffs of those emails/reviews that could be verified. So the signature of the final committer proofs they have verified all previous emails. You still have the email archive to check that if you are really paranoid.=20 > [The Git repo would also need to consume mailing lists somehow and block = any > patches that have not been signed off. But this is orthogonal to > after-the-fact audits, and can basically be thought of as a convenience > measure to protect maintainers from accidentally making un-approved chang= es > that would immediately be caught and reverted.]) I don't believe it is that strict. At some point you just have to trust the final committer to have done all these checks. SLSA doesn't really protect against bad (but trusted insider) actors. See (A3) Code review bypasses that are out of scope of SLSA. > Is there an existing example of an SLSA4 compliant (or at least > trying-in-good-faith) project that has grappled with this kind of workflo= w? > I'm honestly not sure if the tooling to enable it is 100% there, at LF or > anywhere else. >=20 > At the same time it's kind of intriguing to see if this level of paranoia > can be implemented in a somewhat convenient way. I don't know if anybody really does it full paranoid SLSA level 4 for a real community, distributed, upstream development project. But I think tools like gitpw and b4 plus inbox.sourceware.org get us pretty far if people want to = get close. Also you can start with simply adding the patch signoffs to every commit to show the intent of double review, etc. and don't require all the signing st= uff (which is basically what the kernel does). That isn't full SLSA compliant, = but shows the intent. --=20 You are receiving this mail because: You are the assignee for the bug.=