Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 May 2023 11:40:18 -0700 (PDT)
From: Brian Behlendorf <>
Subject: Re: Clarification on embargoed testing in a partner

On Wed, 24 May 2023, Anthony Liguori wrote:
> I think the right policy for list members is that they are responsible for
> understanding the third-party infrastructure they use and if they aren't
> confident that they can maintain the rules of the list, they shouldn't use
> it.

We've known since "On Trusting Trust" that every variable consumed during 
the SDLC is a vector for compromise, even in very subtle and difficult 
(impossible? halting problem?) ways to defeat. Inevitably we need to rely 
on self-attestation, paired with certification processes when called for 
(e.g. FedRamp). There is emerging regulatory action, at least in the US 
(see the new White House Cybersecurity Policy) and the EU's CRA, calling 
for the establishment of clear processes for demonstrating provenance and 
attestation to at least the build environment and likely eventually the 
full SDLC.

A clear and more formal way of understanding the different levels of 
attestation of one's build environment can be found in the SLSA 
specification. Here's a story about how Google Cloud incorporates it into 
build service:

Of course attestation is not proof, and even human certification can only 
go so far. Reproducible builds offer a path there but that goal seems just 
as far away as it was 20 years ago, when Java was going to solve that for 

I have no recommendation on if or how to use SLSA or something like it in 
this policy, just that it may be something to consider.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.