Chains should caution users when configuring it to sign an artifact that it didn't produce
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 277
- Forks
- 164
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 61
Description
Created based on https://github.com/tektoncd/chains/pull/730#discussion_r1179481642
It is generally preferable to sign produced artifacts by the process which generated them in order to more clearly indicate the level of trust which can be associated. As Chains is becoming more capable to sign artifacts (images, SBOMs) which it doesn't produce, the considerations should be documented for users to take into account before enabling this functionality.
Having some signature is better than no signature, it would be preferable to leverage some process like keyless signing and spiffe/spire to enable signing within the pipeline of artifacts generated by the pipeline. If chains only signs the content which it produces (i.e. provenance), then its actions can be more clearly tied to a more trusted service within a build platform.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked pull-request discussion and locate the documentation covering Chains signing images and SBOMs. Document the trust considerations for signing artifacts Chains did not produce, including the preferred in-pipeline signing approach; the issue names no files or tests.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, security
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100