[Bug Infrastructure/29615] prototype & document SOP for signed-git-op repo

["mark at klomp dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29615

--- Comment #6 from Mark Wielaard <mark at klomp dot org> ---
(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 magic
> forge that everyone trusts to securely decide when the merge criteria have
> been met. 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 of a compliant project is SUSE Open Build System, which sounds
> 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 far 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
> 
> (a) the patch series submitted to the mailing list was reviewed & signed off
> by <insert required number of reviewers>
> (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)
> 
> 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 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 use 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-patatt-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 messages,
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. 

> [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 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 workflow?
> I'm honestly not sure if the tooling to enable it is 100% there, at LF or
> anywhere else.
> 
> 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 stuff
(which is basically what the kernel does). That isn't full SLSA compliant, but
shows the intent.

-- 
You are receiving this mail because:
You are the assignee for the bug.