-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provenance v1: Add builder
to the SLSA Provenance model
#593
Comments
This explains how to verify provenance without expanding the requirements of the SLSA Build levels. As discussed at the SLSA Specification SIG meeting on 2023-02-13, adding verification to the existing levels seems like it adds too much complexity. This commit tries to strike the balance of still describing the concept without making it a SLSA requirement. Also clarify the model: - Simplify the diagram's colors (orange = "to be verified", green = "trusted", remove red) and add a legend. (Partially addresses slsa-framework#593.) - Better explain what `buildType` means. - Clarify communication with caches and the platform, and recolor the caches to green since they are covered by the SLSA Build requirement (thus trusted). Signed-off-by: Mark Lodato <lodato@google.com>
This explains how to verify provenance without expanding the requirements of the SLSA Build levels. As discussed at the SLSA Specification SIG meeting on 2023-02-13, adding verification to the existing levels seems like it adds too much complexity. This commit tries to strike the balance of still describing the concept without making it a SLSA requirement. Also clarify the model: - Simplify the diagram's colors (orange = "to be verified", green = "trusted", remove red) and add a legend. (Partially addresses slsa-framework#593.) - Better explain what `buildType` means. - Clarify communication with caches and the platform, and recolor the caches to green since they are covered by the SLSA Build requirement (thus trusted). Signed-off-by: Mark Lodato <lodato@google.com>
This explains how to verify provenance without expanding the requirements of the SLSA Build levels. As discussed at the SLSA Specification SIG meeting on 2023-02-13, adding verification to the existing levels seems like it adds too much complexity. This commit tries to strike the balance of still describing the concept without making it a SLSA requirement. Also clarify the model: - Diagram: - Simplify the diagram's colors (orange = "to be verified", green = "trusted", remove red). - Mark the build cache as green since it's covered by the SLSA Build requirement, thus trusted. - Add a legend (slsa-framework#593.) - Use the same text color as the website. - Better explain what `buildType` means. - Clarify communication with caches and the platform. Signed-off-by: Mark Lodato <lodato@google.com>
I don't have any good idea on how to add it. I'm inclined to close as "won't fix". Any opinions? |
Yes. Indeed. From the description, it is not clear to me if there is a difference between the If so, perhaps we just need to clarify in the description that @asraa Any ideas? |
I think it seems like this. Doesn't the builder/platform provides the |
That makes sense. @MarkLodato I think clarifying what the builder is in "Provenance is an attestation that the builder produced the subject software artifacts through execution of the buildDefinition." will fix this problem. Since the sentence says that the attestation is partly about the builder it is important to be clear what the builder is. |
I've tried this, but it makes the diagram much harder to follow due to the added visual noise. Although it's true, I think it's easier to understand without it. |
In the provenance v1 spec, it would be nice to clarify how the diagram and particularly the "Build Process" relate to the
builder
. The description talks aboutbuilder
but is not shown in the diagram. (Originally posted by @rbehjati in #582 (comment).)I'm not sure how best to do this so I'm creating this issue to track ideas.
First, what exactly is the builder in the diagram? Is it a collection of multiple boxes (e.g. platform, build type, build cache, build process)? Is it just the platform? Does it not really map to the diagram?
Once we decide that, we can figure out how to represent it. For example, I tried adding dashed lines around a collection of boxes but that added too much clutter.
The text was updated successfully, but these errors were encountered: