TEP0122 - Complete build instructions and parameters - implementable

[chitrangpatel]

This proposal was intended to be implementable but was accidentally left in proposed state. Some minor cleanup (accidental buildConfig --> invocation.Parameters) and clarifications were added to make it more readable. No major changes were introduced.

[afrittoli]

Maybe this PR is an opportunity to address #820 (comment)?

[chitrangpatel]

Maybe this PR is an opportunity to address #820 (comment)?

Good point. I will move the conversation here:

What about flags passed to the controller directly at start time?

Hmm. I didn't think of that. Do you mean https:/tektoncd/pipeline/blob/d5f1a1743ff03b5aeee0363c234016d3eaa66d75/config/controller.yaml#L63-L87? If so, yes we should be able to capture the args in materials.

Also, we have a lot of different configuration flags, so it would make sense to specify which ones shall be included.

I was thinking of including them all for completeness since there are only 16 I think.

It feels like this would cause a non-negligable increase in size of the TaskRun resources.

Hmm. Unless I'm misunderstanding, the only features that I'm thinking of are these. Surely, that list could increase over time but probably not too large? That shouldn't be an issue right?
We can definitely update this approach if its not good enough.

Is it a standard SLSA requirement to include the configuration of the build system?

I think SLSA wants reproducibility as best as we can. I think feature flags that were used to configure Tekton that produced the build is very important for reproducibility and for verification. A user may decide that the build was performed using wrong feature flags and may not want to deploy the build.

[bobcatfish]

/approve

[chuangw6]

/assign

[chuangw6]

Synced offline with @chitrangpatel . We need to update the tables to reflect that service account, workspaces etc. provided in taskrun will be recorded in invocation.params instead of buildConfig.

Not sure if it fits into this pr which just moves the tep to implementable. If not, feel free to do it in another pr :d Thanks @chitrangpatel !!

[chuangw6]

Thanks @chitrangpatel for updating this!

[chitrangpatel]

Synced offline with @chitrangpatel . We need to update the tables to reflect that service account, workspaces etc. provided in taskrun will be recorded in invocation.params instead of buildConfig.

Not sure if it fits into this pr which just moves the tep to implementable. If not, feel free to do it in another pr :d Thanks @chitrangpatel !!

I think it fits here. Before making it implementable, its better to address these issues.

[chuangw6]

What about flags passed to the controller directly at start time?
Is it a standard SLSA requirement to include the configuration of the build system?

I think on the surface level, the provenance aims to record the information about the build process of an artifact instead of the build system. There is indeed a field in the SLSA v0.2 provenance named predicate.builder to record the builder information, but it only records the builder identifier.

That said, the SLSA v1.0 design (draft) seems to introduce more fields about builder, and one of them is builderDependencies which seems like a better place for the flags to the controller?

So I am leaning towards making flags out of scope for SLSA v0.2, but I am open to other suggestions here.

cc @afrittoli @chitrangpatel

[chitrangpatel]

@chuangw6 @afrittoli according to https://slsa.dev/provenance/v0.2, invocation.environment is meant to contain any builder-controlled inputs necessary for correctly evaluating the build. Usually only needed for reproducing the build but not evaluated as part of policy.

In slsav0.2, I think this is where config-feature-flags belong and may be also arguments that I think @afrittoli is mentioning.

[chitrangpatel]

/kind tep

[JeromeJu]

/assign @afrittoli

[chuangw6]

/approve

[pritidesai]

API WG - @afrittoli please take a look, this approved by other reviewers. @chitrangpatel to rebase this. Thanks!

[afrittoli]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afrittoli, bobcatfish, chuangw6

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• teps/OWNERS [afrittoli,bobcatfish]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[afrittoli]

Approved in API WG
/lgtm