Unverified Commit 81795370 authored by Tom Hennen's avatar Tom Hennen Committed by GitHub
Browse files

Merge pull request #79 from slsa-framework/TomHennen-patch-1

Allow a service other than the 'build service' to generate provenance
parents 1e6031d7 1f2d87c7
......@@ -294,15 +294,29 @@ all the other requirements.
The provenance's authenticity and integrity can be verified by the consumer.
This SHOULD be through a digital signature from a private key accessible only to
the build service.
the service generating the provenance.
<td> <td><td><td>
<tr id="service-generated">
<td>Service Generated
The provenance was populated by the build service, not by user-provided tooling
running on top of the service.
The data in the provenance MUST be obtained from the build service (either because
the generator _is_ the build service or because the provenance generator reads the
data directly from the build service).
Regular users of the service MUST NOT be
able to inject or alter the contents, except as noted below.
The following provenance fields MAY be generated by the user-controlled build
* The output artifact hash from [Identifies Artifact](#identifies-artifact).
* Reasoning: This only allows a "bad" build to falsely claim that it
produced a "good" artifact. This is not a security problem because the
consumer MUST accept only "good" builds and reject "bad" builds.
* The "reproducible" boolean and justification from
<td> <td><td><td>
<tr id="non-falsifiable">
......@@ -311,6 +325,8 @@ running on top of the service.
Provenance cannot be falsified by the build service's users.
NOTE: This requirement is a stricter version of [Service Generated](#service-generated).
* The provenance signing key MUST be stored in a secure key management system
accessible only to the build service account.
* The provenance signing key MUST NOT be accessible to the environment running
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