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

Attestation is not replaced despite success #2025

Closed
chipzoller opened this issue Jun 24, 2022 · 5 comments
Closed

Attestation is not replaced despite success #2025

chipzoller opened this issue Jun 24, 2022 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@chipzoller
Copy link

chipzoller commented Jun 24, 2022

Description

When replacing an attestation of an identical predicate type (keyless), although the command returns success and states the correct predicate type which should be replaced, when verifying attestations afterwards the new attestation is not reflected.

Version

1.9.0

Reproduce Steps

  1. Create, for example, a Trivy scan on a container image that you wish to have attested. See an example workflow here with all this set up.
  2. Verify the first attestation is correct.
  3. Generate a new scan and replace the existing attestations. It makes no difference if a tag or digest is provided so long as the tag resolves to the same digest.
COSIGN_EXPERIMENTAL=1 cosign attest --replace --predicate scan.json --type https://trivy.aquasec.com/scan/v2 ghcr.io/chipzoller/zulu:latest
  1. Check with verify-attestations command and see that the new attestation is not present. If using the sample workflow above, this can be verified by checking the timestamp field which should be set to the time at which the scan was performed (roughly).
COSIGN_EXPERIMENTAL=1 cosign verify-attestation ghcr.io/chipzoller/zulu:latest | jq -r .payload | base64 --decode | jq > attestationsdecoded.json

See full debug logs here.

@chipzoller chipzoller added the bug Something isn't working label Jun 24, 2022
@developer-guy
Copy link
Member

Hi @chipzoller, we (w/@Dentrax) have investigated this issue. The problem seems related to the go-containerregistry lib, In the cosign v1.9.0, which uses go-containerregistry v0.8.1.

We have compiled the cosign binary from the main branch, which uses go-containerregistry v0.10.0, and everything worked fine. However, we opened an issue on the zulu project side from installing the cosign binary from the main branch. Would you mind confirming that it is working with it?

chipzoller/zulu#2

@developer-guy developer-guy self-assigned this Jul 20, 2022
@Dentrax
Copy link
Member

Dentrax commented Jul 20, 2022

Hey @cpanato! 👋

Is it good time to release cosign 1.9.1? There are more than 350+ changes since last release. Obviously, bumping go-containerregistry is the major one. Also there some good ones such as bumping Go to 1.18, env subcommand, cyclonedx support, cert-extensions verify, etc. Wdyt?

@cpanato
Copy link
Member

cpanato commented Jul 22, 2022

1.10.0 release is out https://github.com/sigstore/cosign/releases/tag/v1.10.0

@chipzoller
Copy link
Author

Confirmed working using Cosign 1.10.0! Nice work, everyone!

@chipzoller
Copy link
Author

Closed in PR #2021, verified in release 1.10.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants