From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id F09F33858C2C; Thu,  1 Jun 2023 19:54:16 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F09F33858C2C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1685649256;
	bh=yQDXrGFRlTuG9K6rHIQ/myEHbBA9ZFkOEbVE+DXYGN0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=TP1q23m0of577qVxqht+bCnwO70RO0ctvTuQ1BmIchDczFiFpQtUiv9v3w7n3CIKY
	 cOF78KEMHMuLggCxqK2I7H1bf9WJh4n+fZrz24aKriYzhRryF39FyEC9p9Ct65ZgVw
	 hOCuwHuT8vFQqB1VSn1iA+WdLJ/UUjVVQli4hRzg=
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: overseers@sourceware.org
Subject: [Bug Infrastructure/29615] prototype & document SOP for
 signed-git-op repo
Date: Thu, 01 Jun 2023 19:54:16 +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: <bug-29615-14326-uRVGe7guOd@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-29615-14326@http.sourceware.org/bugzilla/>
References: <bug-29615-14326@http.sourceware.org/bugzilla/>
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: <overseers.sourceware.org>

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

--- Comment #7 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Mark Wielaard from comment #6)
> (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 m=
agic
> > forge that everyone trusts to securely decide when the merge criteria h=
ave
> > 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 s=
ounds
> > magic-forge-y.
>=20
> Yes, I think it is mostly used for "downstream" (distro like) projects wh=
ere
> the upstream (signed) release tarball is used as trusted input and then a=
ny
> patches on top of that are treated at SLSA4 level.

SLSA v1.0 does not address source threats any more. It only deals with
dependency and build threats. So it just deals with "downstream" uses of
(trusted) releases.

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