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

[mlieberman85]

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]

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]

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]

@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]

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]

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]

Yeah, I was thinking similar.

[zachariahcox]

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.