cmd: dockerfile resolve

[Dentrax]

Fixes #648 Fixes #707

Signed-off-by: Furkan [email protected] Co-authored-by: Batuhan [email protected]

cc @developer-guy

[developer-guy]

Kindly ping folks. It seems everything is ok right now, which means it is ready to merge. 🙋🏻‍♂️

[dlorenc]

Will take a look!

[Dentrax]

Sorry, we dropped the ball here. I think we resolved all reviews.

[Dentrax]

Kind ping here for review 🤗

[codecov-commenter]

Codecov Report

Merging #1120 (0252e6a) into main (01492c6) will increase coverage by 0.19%. The diff coverage is 41.07%.

@@            Coverage Diff             @@
##             main    #1120      +/-   ##
==========================================
+ Coverage   26.52%   26.72%   +0.19%     
==========================================
  Files         131      133       +2     
  Lines        7709     7820     +111     
==========================================
+ Hits         2045     2090      +45     
- Misses       5405     5470      +65     
- Partials      259      260       +1     

Impacted Files	Coverage Δ
cmd/cosign/cli/dockerfile.go	0.00% <0.00%> (ø)
cmd/cosign/cli/options/dockerfile.go	0.00% <0.00%> (ø)
cmd/cosign/cli/dockerfile/resolve.go	54.54% <54.54%> (ø)
cmd/cosign/cli/dockerfile/verify.go	55.55% <100.00%> (+13.88%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[Dentrax]

Rebased from main branch and there are some failing checks. I ran go mod tidy on my local but pushing the changes breaks the compilation, otherwise goreleaser throws diff error. 🤔

[Dentrax]

Rebased, fixed the e2e test. Failing action throws the following error but couldn't understand:

ERROR: unknown cluster "kind"

Can someone please review? Thanks!

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[Dentrax]

Rebased.

[ChaosInTheCRD]

This is great work - but I am wondering whether it makes sense to have functionality like this directly within cosign. Sure it's helpful, but the art of ensuring that pinning images to digest may be better sitting in a different tool (e.g. https://github.com/sethvargo/ratchet), and kind of spans way further than just Dockerfiles.

@dlorenc @Dentrax @mattmoor @imjasonh what are your thoughts on this? Also adding @znewman01 as he has been considering the digest pinning scenario in https://github.com/sigstore/cosign/pull/2313

[znewman01]

I would normally agree—this sounds a little "kitchen sink-y" to me. But I think if we have cosign dockerfile verify in the first place we need to flesh out the rest of the story here.

IMO reason this wouldn't go in another tool like Ratchet would be the separation in the tooling between "resolve" and "verify." It'd be way too easy to "resolve" with Ratchet and wind up with image digests that are untrusted.

TBH my ideal flow would be one-step, checking signatures as part of resolving: cosign dockerfile resolve --key mykey.pub Dockerfile.unpinned > Dockerfile. This is nice because there's no intermediate resolved-but-unverified Dockerfile to accidentally build with.

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions[bot]]

This PR was closed because it has been stalled for 10 days with no activity.