> 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.
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.
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 is our project
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 :-)
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.