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.

Sign up for GitHub

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

Jump to bottom

Clarify how multiple attestations may be needed to verify "source" requirements #241

Closed
mlieberman85 opened this issue Dec 6, 2021 · 8 comments
Closed

Clarify how multiple attestations may be needed to verify "source" requirements #241

mlieberman85 opened this issue Dec 6, 2021 · 8 comments
Labels
clarification Clarification of the spec, without changing meaning policy Policy / verification of provenance source-track

Comments

@mlieberman85
Copy link
Member

Related somewhat to: #129

Even though the provenance spec does allow you to point to source control for "materials," it doesn't allow for the ability to attest to "verified history," "retained indefinitely," or "two-person reviewed." You can implicitly assume if you have a source control uri like git that it's "version controlled."

Another related thing, and I'm unsure if there's an issue for this already but I think the documentation makes it unclear if the expectation is to have multiple attestations associated with an artifact to then allow the client to make a SLSA level judgement or if everything is intended to be included as part of a single attestation. In the case of multiple attestations would a source based one even include a "builder"?

I bring up the above because in secure CI environments you might have separate "builders" performing different tasks for an artifact build. Those builders might have their own identities and the build service might sign provenance based on those identities, e.g. SPIFFE/Spire.

For example, a flow like:

  1. builder A downloads source to shared volume
  2. builder B downloads dependencies to shared volume
  3. builder C with no internet access, etc. (to be hermetic) compiles/packages artifact
  4. builder D publishes artifact to artifact repo
@TomHennen
Copy link
Contributor

This is what I was hoping to address in in-toto/attestation#47 (before we moved SLSA provenance back to this project).

I had a proposal I was running past @joshuagl but we never actually finished it up. I've shared with you to get your feedback too.

Should we continue discussion here or in in-toto/attestation#47 ?

@mlieberman85
Copy link
Member Author

Right, forgot that was over there. Probably makes sense to continue over there for now but maybe leave this ticket open just so people know to look at it the discussion in-toto/attestation#47?

@mlieberman85
Copy link
Member Author

@TomHennen does it make sense to create another github issue for the other thing described above? There might be the need to multiple attestations associated with an artifact based on who is making what claims?

@MarkLodato
Copy link
Member

IMO it makes sense to have this issue be about the general high level problem ("Another related thing...") while in-toto/attestation#47 is about the specific Source Control predicate.

@TomHennen
Copy link
Contributor

TomHennen commented Dec 6, 2021 •
edited
Loading

On that topic I'd suggest we expect there to be multiple different attestations. I think that should make it easier to the processes issuing the attestations to have first-hand knowledge about what it is they're signing.

In your example I think it could work like this:

  1. builder A downloads source & the source control attestation (which builder C can later include in the bundle). It doesn't need to attest to anything.
  2. builder B downloads dependencies to shared volume. It could potentially get the attestations for the dependencies that it's downloading or it could issue an attestation that basically says "builder B downloaded these (so you know they haven't been tampered with since they were downloaded), or maybe it does both?
  3. builder C builds the things from the hermetic location, creates & signs SLSA provenance, and puts it in a bundle with the attestations created/fetched by A&B.
  4. builder D could either:
    a. Check all the attestations (which it gets from C) against some policy before it publishes the artifact.
    b. Upload all the attestations to the repo (so others can check them against some policy).
    c. Both a & b (preferred)

WDYT?

@mlieberman85
Copy link
Member Author

Yeah, I was thinking similar.

@msuozzo msuozzo mentioned this issue Jan 10, 2022
Closed
@MarkLodato MarkLodato added the clarification Clarification of the spec, without changing meaning label Jan 27, 2022
@MarkLodato MarkLodato changed the title Provenance spec doesn't appear to support "source" requirements in a clear way Clarify how multiple attestations may be needed to verify "source" requirements Jan 27, 2022
@MarkLodato MarkLodato added the policy Policy / verification of provenance label Jan 27, 2022
This was referenced Feb 5, 2022
Open
Open
@zachariahcox
Copy link
Contributor

reviving this old, still-relevant, discussion.

My current take would be:

  • builders 1 and 2 have the same basic job -- acquisition and verification of some artifact. If they cannot verify that their artifact meets the minimum requirements for the build, they should "fail fast" before moving anything into a shared drive.
  • It may be that the minimum requirements for inputs to a build may change depending on the type of resource -- source artifacts, internally-built artifacts, externally built or oss artifacts may all have different requirements.
  • Neither builders 1 or 2 need to create any new attestations. The fact that they verified their inputs is encoded into the instructions of the workflow file itself.
  • Builder C can now be safely concerned only with producing its net-new artifact.

@TomHennen TomHennen mentioned this issue Jul 12, 2024
Merged
TomHennen added a commit that referenced this issue Sep 23, 2024
@TomHennen @zachariahcox
@adityasaky @marcelamelara
content: draft: define how downstream users can verify the SLSA sourc…
5c8fa6d 
…e track level of revisions (#1094)

fixes #1071
fixes #1042
refs #241

This PR modifies _draft_ content of the SLSA spec.

## Context

See [discussions
here](https://docs.google.com/document/d/13Xt8mA_2b00McGX2vkyhu4GQdFAqtXPu7YXE8ZA6ISE/edit?resourcekey=0-EqfHF79tUWAKp4PzsE3z1A&tab=t.0#heading=h.fhg4lsemfpz2)
[and
here](https://docs.google.com/document/d/1PwhekVB1iDpcgCQRNVN_aesoVdOiTruoebCs896aGxw/edit#bookmark=id.oqoqjt4urxm).

Google document requires
[slsa-discussion@googlegroups.com](mailto:slsa-discussion@googlegroups.com)
membership.

## VSA for source

Define how downstream users can verify the SLSA source track level of
revisions by using a [VSAs](http://slsa.dev/verification_summary)
produced by the Source Control Platform (SCP).

To use these VSAs users do not need to know the specifics of how any
given SCP or Version Control System (VCS) meets the SLSA source
requirements (which may vary greatly from implementation to
implementation). Instead it is left to the SCP or another trusted
'authority' to make that determination for downstream users.

The question of _how_ the authority ensures those claims to be true is
left undefined in this change.

Future updates can include guidance for how to verify source level when
combined with [build provenance](https://slsa.dev/provenance).

## Example scenario

1. A user wants to verify
9a04d1e
is SLSA source level 3.
2. The user 'trusts' GitHub as the authority for source revisions
managed by GitHub.
3. The user requests a VSA for
9a04d1e
from a TBD API
4. The user verifies the VSA following [the standard
instructions](https://slsa.dev/spec/draft/verification_summary#how-to-verify)
or using [standard
tooling](https://github.com/slsa-framework/slsa-verifier?tab=readme-ov-file#verification-summary-attestations-vsa)
and looking for `SLSA_SOURCE_LEVEL_2` in the `verifiedLevels` field.

---------

Signed-off-by: Tom Hennen <tomhennen@google.com>
Signed-off-by: Tom Hennen <TomHennen@users.noreply.github.com>
Co-authored-by: Zachariah Cox <zachariahcox@github.com>
Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com>
Co-authored-by: Marcela Melara <marcela.melara@intel.com>
@zachariahcox zachariahcox closed this as completed by moving to Done in SLSA Source Track Sep 30, 2024
@zachariahcox
Copy link
Contributor

marking this as closed for the moment -- i believe this topic was covered by: #1094

zachariahcox added a commit to zachariahcox/slsa that referenced this issue Oct 1, 2024
@TomHennen @zachariahcox
@adityasaky @marcelamelara
content: draft: define how downstream users can verify the SLSA sourc…
882a5f1 
…e track level of revisions (slsa-framework#1094)

fixes slsa-framework#1071
fixes slsa-framework#1042
refs slsa-framework#241

This PR modifies _draft_ content of the SLSA spec.

See [discussions
here](https://docs.google.com/document/d/13Xt8mA_2b00McGX2vkyhu4GQdFAqtXPu7YXE8ZA6ISE/edit?resourcekey=0-EqfHF79tUWAKp4PzsE3z1A&tab=t.0#heading=h.fhg4lsemfpz2)
[and
here](https://docs.google.com/document/d/1PwhekVB1iDpcgCQRNVN_aesoVdOiTruoebCs896aGxw/edit#bookmark=id.oqoqjt4urxm).

Google document requires
[slsa-discussion@googlegroups.com](mailto:slsa-discussion@googlegroups.com)
membership.

Define how downstream users can verify the SLSA source track level of
revisions by using a [VSAs](http://slsa.dev/verification_summary)
produced by the Source Control Platform (SCP).

To use these VSAs users do not need to know the specifics of how any
given SCP or Version Control System (VCS) meets the SLSA source
requirements (which may vary greatly from implementation to
implementation). Instead it is left to the SCP or another trusted
'authority' to make that determination for downstream users.

The question of _how_ the authority ensures those claims to be true is
left undefined in this change.

Future updates can include guidance for how to verify source level when
combined with [build provenance](https://slsa.dev/provenance).

1. A user wants to verify
slsa-framework@9a04d1e
is SLSA source level 3.
2. The user 'trusts' GitHub as the authority for source revisions
managed by GitHub.
3. The user requests a VSA for
slsa-framework@9a04d1e
from a TBD API
4. The user verifies the VSA following [the standard
instructions](https://slsa.dev/spec/draft/verification_summary#how-to-verify)
or using [standard
tooling](https://github.com/slsa-framework/slsa-verifier?tab=readme-ov-file#verification-summary-attestations-vsa)
and looking for `SLSA_SOURCE_LEVEL_2` in the `verifiedLevels` field.

---------

Signed-off-by: Tom Hennen <tomhennen@google.com>
Signed-off-by: Tom Hennen <TomHennen@users.noreply.github.com>
Co-authored-by: Zachariah Cox <zachariahcox@github.com>
Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com>
Co-authored-by: Marcela Melara <marcela.melara@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clarification Clarification of the spec, without changing meaning policy Policy / verification of provenance source-track
Projects
Issue triage
Status: ✅ Done
SLSA Source Track
Status: Done
Milestone
No milestone
Development

No branches or pull requests
4 participants
@MarkLodato @mlieberman85 @TomHennen @zachariahcox