Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cosign 2.0 Tracking #2376

Closed
3 tasks
haydentherapper opened this issue Oct 24, 2022 · 29 comments
Closed
3 tasks

Cosign 2.0 Tracking #2376

haydentherapper opened this issue Oct 24, 2022 · 29 comments
Labels
enhancement New feature or request

Comments

@haydentherapper
Copy link
Contributor

Description

This is an issue to track Cosign 2.0, with the primary change being the removal of the experimental flag. I've added some initial issues I think would be in scope, feel free to discuss and edit. We should also triage open bugs.

There's also the open question of sigstore-go - Should Cosign 2.0 also involve the redesign of the Cosign API? I'm thinking no, let's narrowly scope 2.0 to focus on client work to support GA, and a 3.0 release could be focused on library redesign.

cc @znewman01 @priyawadhwa

@haydentherapper haydentherapper added the enhancement New feature or request label Oct 24, 2022
@asraa
Copy link
Contributor

asraa commented Oct 24, 2022

I'd like to propose another thing: conglomerating all the env vars we use for pinning rekor/ct/fulcio keys and creating a Root provider interfact, that either uses TUF or populates with any env vars that are enabled.

This would be a MAJOR cleanup and help people use cosign in special environments.

All commands should ingest a Root provider options in the sign/verify/etc options

@znewman01
Copy link
Contributor

See also: #2365 especially the proposal to separate the CLI versioning and the library versioning, and the proposal to provide no guarantees about API stability.

I'm in favor of a quick, relatively narrow 2.0 (scoped to CLI only) because dropping COSIGN_EXPERIMENTAL is a big win and because a long-lived v2-staging branch is a recipe for headache. While we're in there, we should skim for deprecated functionality and things we've been planning to yank, too. So a quick cleanup around env vars SGTM, but I'm a little skeptical of a total refactor of the root provider. I think that would fold nicely into the sigstore-go work, though.

@priyawadhwa
Copy link
Contributor

Thanks for opening this tracking issue @haydentherapper! +1 to a narrow-scoped 2.0, I think all the tagged issues are in-scope. For the root provider refactor, I'm ok not making it a requirement for 2.0 but if it gets in by the time we're ready to release that would be awesome :)

@asraa
Copy link
Contributor

asraa commented Oct 25, 2022

I'm ok not making it a requirement for 2.0 but if it gets in by the time we're ready to release that would be awesome :)

I think that's fair: if we can make the requirement of ripping out any TUF calls from the internal verification functions I think that would suffice! Doing it quickly makes sense. @vaikas

@asraa
Copy link
Contributor

asraa commented Oct 25, 2022

This would be great: #2222

I can work on it soon

@asraa
Copy link
Contributor

asraa commented Oct 25, 2022

To some degree, all bugs should technically be fixed before a major release.
#2138

I think it should be replaced with https://github.com/sigstore/cosign/blob/main/cmd/cosign/cli/verify/verify_blob_attestation.go and we should remove the verify-blob support for attestations.

@asraa
Copy link
Contributor

asraa commented Oct 25, 2022

This too: #2219 @bobcallaway

@haydentherapper
Copy link
Contributor Author

I'd like to add #2382 - This would require that an SCT is provided as proof the certificate is logged in a CT log, unless an insecure flag is provided. This was what we always should have done, but couldn't because old certs didn't have embedded SCTs.

@haydentherapper
Copy link
Contributor Author

+1 to bugs being fixed, should we set up some time to triage open bugs?

@bobcallaway
Copy link
Member

This too: #2219 @bobcallaway

Agreed, that is dependent on Rekor changes sigstore/rekor#1139 and sigstore/rekor#1144 going live in production

@haydentherapper
Copy link
Contributor Author

Would like to add #1762 so that Cosign stops calling the legacy API for Fulcio

@haydentherapper
Copy link
Contributor Author

Another AI, we need to update documentation and blog posts

@haydentherapper
Copy link
Contributor Author

We did some triaging in the GA sync for PRs and issues that we would like to include in 2.0 and a 2.0 release candidate:

  • cosign#2411 - Requiring identity flags (2.0-blocker)
  • cosign#2482 - Refactoring verification (2.0-blocker)
    • cosign#2504 - Split of 2482, just contains certificate expiration (RC-blocker)
  • cosign#2499 - Updates to Timestamping (RC-blocker)
  • cosign#2505 - Respect tlog-upload=false (2.0-blocker)
  • cosign#1762 - Switch to calling gRPC-based fulcio v2 APIs (2.0-blocker)
  • cosign#2047 - Discourage signing references to images that aren't digests (2.0-blocker)

Maybe blockers:

@znewman01
Copy link
Contributor

Okay, all our RC-blockers are merged. CC @cpanato can you help cut a 2.0 rc1 when you get a chance?

@haydentherapper
Copy link
Contributor Author

haydentherapper commented Dec 9, 2022

For 2.0, I’d like to also update the timestamp verification to use the latest version once we cut a new release. We should also verify the timestamp on signing, #2488

@haydentherapper
Copy link
Contributor Author

We need to remove references to COSIGN_EXPERIMENTAL in code (tests and CLI docs), documentation, and blog posts. We also need to update documentation with any new required flags (like identity flags) and optional flags (like tlog-upload).

@hectorj2f
Copy link
Contributor

I have updated the list of pending issues:

  • cosign#2411 - Requiring identity flags (2.0-blocker)
  • cosign#1762 - Switch to calling gRPC-based fulcio v2 APIs (2.0-blocker)
  • cosign#2047 - Discourage signing references to images that aren't digests (2.0-blocker)

Maybe blockers:

@haydentherapper
Copy link
Contributor Author

haydentherapper commented Dec 12, 2022

Updating the list with the latest PRs:

2.0.1 release:

Nice to have:

@haydentherapper
Copy link
Contributor Author

Happy new year! Going to ping everyone for status updates for the remaining PRs:

@mtrmac
Copy link
Contributor

mtrmac commented Jan 4, 2023

I do want to get #2482 done, but I can probably only return to that next month or so. IIRC there are no functional changes remaining (the timestamp semantics changes have already been merged), it’s “just” structural cleanup now.

@haydentherapper
Copy link
Contributor Author

Thanks, so I think we can remove it as a blocker then if it’s just internal cleanup.

@mtrmac
Copy link
Contributor

mtrmac commented Jan 4, 2023

FWIW, my wish for 2.0 would be to change the cosign payload, and the cosign sign UI, so that the payload contains name:tag and the UI is cosign sign --digest sha256:… name:tag, instead of the current 2.0 behavior of pushing users towards cosign sign name@sha256:…. (In short, the rationale is that signing app:10.0, and enforcing that the signed tag matches, protects against registries maliciously substituting a previously-correctly-signed app:0.0.1-beta-auth-not-working-yet.)

I realize this is probably not the time or place (and I haven’t done any work towards this), I’m bringing it up just in case circumstances happen to align…

@haydentherapper
Copy link
Contributor Author

Do you want to chime in on #2047 about that?

@Dentrax
Copy link
Member

Dentrax commented Jan 24, 2023

I'm curious if it's worth to include the #1532 for legacy annotation changes.

@haydentherapper
Copy link
Contributor Author

I’d lean towards not including it to minimize more breaking changes and making it harder to adopt, but we should track that for a future major release (we’ve talked about reworking CLI flags for that for example)

@haydentherapper
Copy link
Contributor Author

I've updated #2376 (comment) to move two issues into a fast followup release, as they aren't breaking changes but we do want to resolve them soon.

@znewman01
Copy link
Contributor

Where are we at with Cosign 2.0? RC1 has been available for the better part of a week: https://github.com/sigstore/cosign/releases/tag/v2.0.0-rc.1

I would actually like to request including #2674 which fixes a regression for prompts on Windows but otherwise I'm ready to pull the trigger.

CC @priyawadhwa

@xopham
Copy link

xopham commented Feb 24, 2023

Adding proper error codes would be a great improvement for any type of integration: #2742. At Connaisseur, we tend to struggle with parsing the unhandled and frequently changing outputs of cosign which complicates interpretation of the validation result.

I would propose returning proper error codes. Would be great to improve compatibility.

@znewman01
Copy link
Contributor

2.0 is out, so closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants