Remove TaskRunResults from slsa/v2alpha1

[chitrangpatel]

PR #663 added taskRunResults to the buildConfig.

However, the buildConfig should only be static information from the build configuration, not the runtime info too and taskRunResults is definitely runtime information.
Having said that, I'm not sure where we would fit the taskRunResults in this case because there is no obvious place in the SLSAv0.2 predicate.

We could reach out to the SLSA folks and ask for guidance on this. But as is, I don't think taskRunResults belongs in the buildConfig should probably be removed.

Thoughts???

[chitrangpatel]

cc @bobcatfish @chuangw6 @wlynch @lcarva

[chitrangpatel]

/kind bug

[lcarva]

Runtime information, like TaskRun results, is super valuable when writing advanced policies. The new SLSA spec will have a place for this under byproducts, see #649. But I think that may not be sufficient. For instance, tracking the order the TaskRuns were executed might be challenging.

We may want to introduce a new predicate that includes pretty much the whole TaskRun/PipelineRun resource.

That way, Chains can generate a very clean SLSA Provenance attestation which makes most users happy. But also a Chains specific attestation for those of us who need additional information in their policies.

[wlynch]

+1 to what @lcarva said. There's still value in storing the result values, though I'm fine if we move them out of buildConfig to somewhere else (byproducts, etc).

I like the idea of attaching the full spec as it's own separate attestation that's linked to from the main SLSA attestation. This is also a nice pattern to let us eventually attach additional attestations like Pod spec as well.

[chitrangpatel]

The challenge is that in SLSA v0.2, there is no obvious place for this. In SLSA v1.0, we can certainly add it to byProducts. My feeling is that we should stick to the recommendations set out by SLSA for those implementations. Because if we are claiming that we are using the SLSA predicate and requirements then we should comply with their recommendations.

If we need more information then we can do what @lcarva suggested - i.e. implement a chains specific attestation (which provides more information on top of what SLSA is recommending)?

[wlynch]

Since SLSA v1 sounds like it is imminent (last I heard ETA for final v1 spec was mid-late April), one option is we freeze support for SLSA v0.2 in our v1 spec, and focus on SLSA v1 for v2. This would sidestep the issue for v0.2.

If we have a reason to keep developing against SLSA v0.2 - we could find another home like extending invocation with our own fields that we need. I see enough value for these fields that I wouldn't want to just drop them without a replacement.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.