3 ms·

The post mentions SLSA level 2. Here are the SLSA levels, for those not familiar with them: https://slsa.dev/spec/v1.0/levels https://slsa.dev/spec/v1.0/levels

The post mentions SLSA level 2. Here are the SLSA levels, for those not familiar with them: https://slsa.dev/spec/v1.0/levels https://slsa.dev/spec/v1.0/levels Here's the full spec from its beginning: https://slsa.dev/spec/v1.0/ https://slsa.dev/spec/v1.0/ For those saying we should have verified reproducible builds: yes, that'd be great! This effort does not conflict with reproducible builds. However, some builds are hard to reproduce. Making sure you protect the build process itself is a great first step.

csande17 3y ago
> For those saying we should have verified reproducible builds: yes, that'd be great! This effort does not conflict with reproducible builds. Well, we can hope, anyway. "Provenance" necessarily involves injecting secret data into the build process so that it can't be reproduced by third parties. It's mostly a question of how careful you are to keep the keys / signatures completely separate from all of the other build inputs and outputs. Some code signing systems make that pretty difficult.
- kylegalbraith 3y ago
  What are some of the systems that make that difficult?
- colek42 3y ago
  Provenance is NOT injecting secret data into the build process. Provenance (scoped to supply chain security) is a document that describes the process in which the artifact goes through to become an artifact, to include all steps such as testing, GRC, etc. in-toto is a great way to describe provenance. I talk about it in the CNCF blog article: https://www.cncf.io/blog/2023/08/17/unleashing-in-toto-the-api-of-devsecops/ https://www.cncf.io/blog/2023/08/17/unleashing-in-toto-the-a... Disclaimer, I am a member if the in-toto steering committee and the CEO of a software supply chain startup, Testifysec. https://github.com/in-toto/witness https://github.com/in-toto/witness is our project
  - woodruffw 3y ago
    The context here is signed build provenance, which does involve injecting a secret (or more accurately, some publicly verifiable credential that only an a priori trusted party can mint or otherwise issue for) into the context that the provenance belongs to. You're right that provenance itself doesn't require this, but that is principally because it punts on the problem of authenticity. Whether or not authenticity matters probably depends on the value and scope of the provenance's use :-)

csande17 3y ago

> For those saying we should have verified reproducible builds: yes, that'd be great! This effort does not conflict with reproducible builds. Well, we can hope, anyway. "Provenance" necessarily involves injecting secret data into the build process so that it can't be reproduced by third parties. It's mostly a question of how careful you are to keep the keys / signatures completely separate from all of the other build inputs and outputs. Some code signing systems make that pretty difficult.

kylegalbraith 3y ago
What are some of the systems that make that difficult?
colek42 3y ago
Provenance is NOT injecting secret data into the build process. Provenance (scoped to supply chain security) is a document that describes the process in which the artifact goes through to become an artifact, to include all steps such as testing, GRC, etc. in-toto is a great way to describe provenance. I talk about it in the CNCF blog article: https://www.cncf.io/blog/2023/08/17/unleashing-in-toto-the-api-of-devsecops/ https://www.cncf.io/blog/2023/08/17/unleashing-in-toto-the-a... Disclaimer, I am a member if the in-toto steering committee and the CEO of a software supply chain startup, Testifysec. https://github.com/in-toto/witness https://github.com/in-toto/witness is our project
- woodruffw 3y ago
  The context here is signed build provenance, which does involve injecting a secret (or more accurately, some publicly verifiable credential that only an a priori trusted party can mint or otherwise issue for) into the context that the provenance belongs to. You're right that provenance itself doesn't require this, but that is principally because it punts on the problem of authenticity. Whether or not authenticity matters probably depends on the value and scope of the provenance's use :-)