From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CE249385843A; Tue, 27 Sep 2022 13:23:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CE249385843A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1664285010; bh=MJQ5jM7oYI6IMnRMxO3hTDZ4J3wQOwm5tzdYD6I1UYs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vdIRitdwFvwS2s6bdaf9wPkNMjXkGVwFn9pDnc9+rKhvX3msu216iLmwqoZ6HKuSl nvEnrRwjPGsKyA6sLLM8y2Ky+XrYJGeS1hORf0EZfEN0IWEVGyv+LCqUSblk4/hl5S 9UfAa6atZGB9FAK2jO2ybmYaXArj7t5Z36zat/m4= From: "serhei at serhei dot io" To: overseers@sourceware.org Subject: [Bug Infrastructure/29615] prototype & document SOP for signed-git-op repo Date: Tue, 27 Sep 2022 13:23:30 +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: serhei at serhei dot io 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 #5 from Serhei Makarov --- One issue with the SLSA4 checklist is that SLSA4 seems to be written in a w= ay that assumes developers are reviewing pull requests and there's a magic for= ge that everyone trusts to securely decide when the merge criteria have been m= et. Applying it to individual commits on a mailing-list workflow will be tricky= and AFAIK the kernel isn't currently doing that. The example on SLSA4 website o= f a compliant project is SUSE Open Build System, which sounds magic-forge-y. (Just trying to wrap my head around how it would hypothetically look. In fully-paranoid SLSA4, we would need to verify (a) the patch series submitted to the mailing list was reviewed & signed of= f by (b) the patch series committed to the Git repo matches exactly what was sig= ned off in the mailing list (no last-minute good-Samaritan fixup by the maintai= ner) 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 fact, 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 forge'. [*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 archives and fl= ags any commits that don't have two matching, GPG-signed Signed-Off-By: replies= by reviewers.] [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 changes that would immedia= tely be caught and reverted.]) Is there an existing example of an SLSA4 compliant (or at least trying-in-good-faith) project that has grappled with this kind of workflow?= I'm honestly not sure if the tooling to enable it is 100% there, at LF or anywh= ere else. At the same time it's kind of intriguing to see if this level of paranoia c= an be implemented in a somewhat convenient way. --=20 You are receiving this mail because: You are the assignee for the bug.=