Commit fdcd336d authored by Mark Lodato's avatar Mark Lodato
Browse files

Require Reproducibility or a justification.

Previously we only "recommended" reproducibility. This was both very
weak and also unenforceable.

Now we require Reproducibility unless there is a justification why it is
not. This is a much stronger motivation to make things Reproducible: it
is the path of least resistance. Furthermore, this can now be checked
in an automated way: either the "reproducible" bit is set or the
"justification" is non-empty. We will likely want to have an enum of
valid justifications, but that will be decided once we write detailed
builder requirements.
parent 5310e40a
...@@ -185,7 +185,7 @@ more, see [Threats, Risks, and Mitigations in the Open Source Ecosystem]. ...@@ -185,7 +185,7 @@ more, see [Threats, Risks, and Mitigations in the Open Source Ecosystem].
[benefits](https://static.googleusercontent.com/media/sre.google/en//static/pdf/building_secure_and_reliable_systems.pdf#page=357), [benefits](https://static.googleusercontent.com/media/sre.google/en//static/pdf/building_secure_and_reliable_systems.pdf#page=357),
including easier debugging, more confident cherry-pick releases, better build including easier debugging, more confident cherry-pick releases, better build
caching and storage efficiency, and accurate dependency tracking. For these caching and storage efficiency, and accurate dependency tracking. For these
reasons, we recommend reproducibility and require hermeticity at SLSA 3. reasons, we require reproducibility and hermeticity at SLSA 3 by default.
In terms of security, _verified_ reproducible builds are often In terms of security, _verified_ reproducible builds are often
[suggested](https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/) [suggested](https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/)
...@@ -217,9 +217,9 @@ chain integrity, nor are they practical in all cases: ...@@ -217,9 +217,9 @@ chain integrity, nor are they practical in all cases:
many cases, or develop multiple, independent in-house rebuilders, which is many cases, or develop multiple, independent in-house rebuilders, which is
likely prohibitively expensive. likely prohibitively expensive.
For these reasons, we do not _require_ reproducible builds as part of SLSA. For these reasons, we do not strictly require reproducible builds as part of
Instead, it is best to think of verified reproducible builds as one option for SLSA. Instead, we only _recommend_ reproducibility at SLSA 3 and allow verified
implementing some of the SLSA requirements. reproducible builds as one option for meeting the build requirements.
For more on reproducibility, see For more on reproducibility, see
[Hermetic, Reproducible, or Verifiable?](https://sre.google/static/pdf/building_secure_and_reliable_systems.pdf#page=357) [Hermetic, Reproducible, or Verifiable?](https://sre.google/static/pdf/building_secure_and_reliable_systems.pdf#page=357)
...@@ -346,7 +346,7 @@ Each SLSA level has a set of requirements. ...@@ -346,7 +346,7 @@ Each SLSA level has a set of requirements.
Legend: Legend:
* ✓ = required at this level * ✓ = required at this level
* ○ = recommended at this level, but not strictly required * ○ = required at this level unless there is a justification
*\* = required at this level, but best effort because it depends on *\* = required at this level, but best effort because it depends on
hermeticity, which is not required at this level hermeticity, which is not required at this level
* † = detection is allowed instead of prevention * † = detection is allowed instead of prevention
...@@ -376,8 +376,8 @@ nuanced. We only provide a brief summary here for clarity. ...@@ -376,8 +376,8 @@ nuanced. We only provide a brief summary here for clarity.
* **[Hermeticity]** All build steps, sources, and dependencies were fully * **[Hermeticity]** All build steps, sources, and dependencies were fully
declared up front and the build steps ran with no network access. declared up front and the build steps ran with no network access.
* **[Reproducibility]** Re-running the build steps with identical input * **[Reproducibility]** Re-running the build steps with identical input
artifacts results in bit-for-bit identical output. (Strongly recommended but artifacts results in bit-for-bit identical output. (Builds that cannot meet
not required.) this must provide a justification.)
* **[Source Integrity]** All input artifacts were fetched in a manner that * **[Source Integrity]** All input artifacts were fetched in a manner that
prevents tampering, such as TLS. prevents tampering, such as TLS.
* **[Provenance]** Signed provenance recorded the input artifacts, output * **[Provenance]** Signed provenance recorded the input artifacts, output
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment