Skip to content
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

Closed
MarkLodato opened this issue Jan 27, 2023 · 6 comments · Fixed by #712
Closed

Provenance v1: Add builder to the SLSA Provenance model #593

MarkLodato opened this issue Jan 27, 2023 · 6 comments · Fixed by #712
Labels
clarification Clarification of the spec, without changing meaning provenance Applies to SLSA provenance spec

Comments

@MarkLodato
Copy link
Member

MarkLodato commented Jan 27, 2023

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 about builder 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.

@MarkLodato
Copy link
Member Author

Also add a legend:

  • Green = trusted, does not require verification
  • Orange = external
  • Grey = logical, doesn't really exist
  • Red = the build process itself, red because it's under the tenant's control

Probably need to update the intro text to better explain and account for this.

SLSA Build Model v1 0

MarkLodato added a commit to MarkLodato/slsa that referenced this issue Feb 15, 2023
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>
MarkLodato added a commit to MarkLodato/slsa that referenced this issue Feb 15, 2023
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>
MarkLodato added a commit to MarkLodato/slsa that referenced this issue Feb 15, 2023
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>
@MarkLodato
Copy link
Member Author

I don't have any good idea on how to add it. I'm inclined to close as "won't fix". Any opinions?

@MarkLodato MarkLodato added clarification Clarification of the spec, without changing meaning provenance Applies to SLSA provenance spec labels Mar 6, 2023
@rbehjati
Copy link

rbehjati commented Mar 6, 2023

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?

Yes. Indeed. From the description, it is not clear to me if there is a difference between the builder and the platform. The description says that builder.id identifies the platform. From this, is it correct to conclude that builder and the platform are essentially the same thing?

If so, perhaps we just need to clarify in the description that builder is short for build platform. Also we often talk about a trusted builder. Is it the same as the platform?

@asraa Any ideas?

@asraa
Copy link
Contributor

asraa commented Mar 6, 2023

If so, perhaps we just need to clarify in the description that builder is short for build platform. Also we often talk about a trusted builder. Is it the same as the platform?

I think it seems like this.

Doesn't the builder/platform provides the System Parameters? so it might be worth putting a dotted arrow saying -- provides -->.

@rbehjati
Copy link

rbehjati commented Mar 8, 2023

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.

@MarkLodato
Copy link
Member Author

Doesn't the builder/platform provides the System Parameters? so it might be worth putting a dotted arrow saying -- provides -->.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Clarification of the spec, without changing meaning provenance Applies to SLSA provenance spec
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants