How to communicate SLSA source track metadata?

[TomHennen]

Builds have provenance. Source track doesn’t (it was explicitly removed from this PR).

@Nikokrock says:

I missed the time when the idea of the provenance for sources was removed. I think that we probably should converge on whether we want them or not in the track. If you had that to L1 it gives L1 more value as the person even if not using a SCP will emit from time to time an attestation that will be public and easily shareable. I still think that the attestation should be link to a revision (i.e based on the hash of the content). This gives the ability to compare two revisions independently from the VCS and SCP used. tomhennen@google.com I have read the main points of the proposal from 2-3 years ago and I was wondering whether there was a reason it was abandoned ?

In the SLSA specification meeting on June 17th this [was discussed] (https://docs.google.com/document/d/1PwhekVB1iDpcgCQRNVN_aesoVdOiTruoebCs896aGxw/edit#bookmark=id.oqoqjt4urxm) (note that this isn't necessarily 'final' we can discuss more here?):

Split into 1. “how do consumers know the status as communicated by some authority” and 2. “how does that authority know the status is true” (gittuf could likely fill this role)

1. We can do ‘now’ with blind trust on the SCP (to unblock immediate progress)
2. Would let us remove the need to trust the SCP

We SHOULD NOT have anything in the spec that relies on a specific implementation of a control (e.g. a specific way to validate identity)

[TomHennen]

In a comment thread on a doc on this topic I said:

@roche@adacore.com I don't think the intent was to drop it from the track entirely for v1.1, just to drop it from this draft of the PR to allow it to be iterated on separately.

I think it's definitely something that should be in scope for the final v1.1.

FWIW internally we did wind up taking a different approach where the SCP provides an API for the builder to call and get metadata about the protection status of the repo at that commit. The builder then embeds that information directly to the build provenance. That would up being easier for our internal partners to implement and it did make evaluation easier too. But it does have its downsides.

It winds up looking something like this:

"resolvedDependencies": [{
  // The git repo that contains the build.yaml referenced above.
  "uri": "git+[https://github.com/foo/bar.git](https://www.google.com/url?q=https://github.com/foo/bar.git&sa=D&source=docs&ust=1718640718887393&usg=AOvVaw2K9aO8Nvg5jQpiLdhA9hlj)",
  // The resolved git commit hash reflecting the version of the repo used for this build.
  "digest": {"gitCommit": "abc..."}
  "annotations": {
    "SLSA_STATUS": { "level": "SLSA_SOURCE_L2" }
  }
}]

But the main point is... yes, we absolutely need some method of communicating this data, I think it should absolutely be > in v1.1, but let's handle defining it in a separate issue/PR?

[TomHennen]

See additional discussion here