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
[bug] "Generate builder" and "Run sigstore/cosign-installer" steps failing with error updating to TUF remote mirror: invalid key
#3350
Comments
Started seeing the same just now. |
+1 Seeing this across all our builds in the last 2 hours... this is holding up our release candidate...
|
|
@laurentsimon @ianlewis You just need to bump Cosign to at least v2.2.0, latest is v2.2.3. I'd also recommend checking your renovate settings, I would have expected this bump to get picked up automatically. |
Versions of Cosign before v2.2.0 are not compatible with the latest TUF root. Fixes slsa-framework#3350 Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
@haydentherapper Cosign in SLSA Verifier needs to be updated to the latest version as well. |
According to the announcement, v2.2.0 should support a new TUF Trust root, so I don't think we need to update Cosign in SLSA Verifier. |
I see. The latest slsa-github-generato v1.9.0 uses the old slsa-verifier which uses the old cosign v2.0.2
The main branch uses the latest slsa-verifier v2.4.1.
So we need to release a new version of slsa-github-generator, then the issue would be solved. |
@laurentsimon @ianlewis |
Hi, yes let's do that. I think we need to revert a few breaking PRs we made recently in the slsa-github-generator. slsa-verifier should be ready to be released. @ramonpetgrave64 could you send PRs to temporarily revert the few breaking PRs we made recently? |
Note: slsa-verifier's latest version uses cosign 2.2.0 https://github.com/slsa-framework/slsa-verifier/blob/v2.4.1/go.mod so need not be updated. |
Versions of Cosign before v2.2.0 are not compatible with the latest TUF root. Fixes #3350 # Summary ... ## Testing Process ... ## Checklist - [ ] Review the contributing [guidelines](./../CONTRIBUTING.md) - [ ] Add a reference to related issues in the PR description. - [ ] Update documentation if applicable. - [ ] Add unit tests if applicable. - [ ] Add changes to the [CHANGELOG](./../CHANGELOG.md) if applicable. --------- Signed-off-by: Hayden Blauzvern <hblauzvern@google.com> Signed-off-by: Bob Callaway <bcallaway@google.com> Co-authored-by: Bob Callaway <bcallaway@google.com>
# Summary Update changelog for #3350 ## Testing Process ... ## Checklist - [ ] Review the contributing [guidelines](./../CONTRIBUTING.md) - [ ] Add a reference to related issues in the PR description. - [ ] Update documentation if applicable. - [ ] Add unit tests if applicable. - [ ] Add changes to the [CHANGELOG](./../CHANGELOG.md) if applicable. --------- Signed-off-by: laurentsimon <laurentsimon@google.com>
I see this is closed, but
Can this bug be reopened until a release occurs? Or is there a way to work around this, or can we use the generator at cc / @laurentsimon @ianlewis |
Generator at main won't pass verification. We need to cut the release. @kpk47 is working on it |
Thank you @laurentsimon for being so responsive on this issue; I understand the commit auto-closed the bug. It's helpful to have something to follow. Good luck and thank you for your hard work securing software supply chains. |
Works again for me with the un-finalized v1.10.0 pre-release. |
Release is available v1.10.0 https://github.com/slsa-framework/slsa-github-generator/releases/tag/v1.10.0 |
Versions of Cosign before v2.2.0 are not compatible with the latest TUF root. Fixes slsa-framework/slsa-github-generator#3350 ... ... - [ ] Review the contributing [guidelines](./../CONTRIBUTING.md) - [ ] Add a reference to related issues in the PR description. - [ ] Update documentation if applicable. - [ ] Add unit tests if applicable. - [ ] Add changes to the [CHANGELOG](./../CHANGELOG.md) if applicable. --------- Signed-off-by: Hayden Blauzvern <hblauzvern@google.com> Signed-off-by: Bob Callaway <bcallaway@google.com> Co-authored-by: Bob Callaway <bcallaway@google.com>
I upgraded to |
@ddworken The latest version of slsa-verifier is still is able to verify old provenances. Why do you need to use an old version of slsa-verifier? @haydentherapper @bobcallaway Probably unrelated to this issue but what is the Sigstore/Cosign solution for revoked root keys and in general how does Sigstore provide backward compatibility with old versions of certificates, and therefore verifying existing legitimate provenances that were signed with revoked keys? |
The issue is that the old version of slsa-verifier isn't able to verify releases that were formerly valid. My project uses SLSA for releases and secure updates. I have daily tests running on Github Actions and it went from passing to failing in line with this bug: You can see the test failure here. I also confirmed that this appears to apply to the main
This fails with the output: slsa-verifier output
So it seems to me that slsa-verifier is now failing to verify attestations that used to pass. It is true that the latest version of slsa-verifier is able to verify old attestations, but this doesn't seem to help anyone who is stuck with an old version of slsa-verifier.
This is because my project embeds slsa-verifier in order to provide secure updates. So when slsa-verifier suddenly breaks in this way, it means that any clients with the old version of slsa-verifier become effectively stranded since they cannot upgrade to new versions. |
@behnazh-w Supporting validity windows was the motivation behind the design of the trust root spec. For each root of trust, a validity time period is specified. If a compromise were to occur, rather than revoking the root material entirely and assuming we can determine the window when compromise occurred, the root material would simply be specified as valid only up to the compromise. All Sigstore clients (eg sigstore-python, js, etc) but Cosign support ingesting the roots of trust in this format currently. Cosign will be updated to read it soon. |
You're correct. The TUF root updates need an update of slsa-verifier to v2.4.1. We could backport the fixes, but it would still require you to update your slsa-verifier version. |
Got it, thanks for confirming! I'm wondering: Is this class of breakage something you expect to continue to need to happen with slsa-verifier? If so, it seems like this may be an important caveat to document (maybe under the "Known Isssues" heading) since having a previously working verifier continue to work seems like a reasonable expectation. |
We don't expect this to happen. @haydentherapper can comment on the specifics of cosign. |
Breaking changes are not something that is going to happen frequently and if they do, there will be a significant period of time to have clients migrate over. |
SLSA breaking change requires an update of the action to 1.10: slsa-framework/slsa-github-generator#3350
…trieving Rekor public keys (#386) Provenance generation fails due to Rekor public key errors were identified as a known issue and fixed in version 1.10.0 per: slsa-framework/slsa-github-generator#3350
…trieving Rekor public keys (#265) **Requirements** - [ ] I have added test coverage for new or changed functionality - [ ] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [ ] I have validated my changes against all supported platform versions **Describe the solution you've provided** Provenance generation fails due to Rekor public key errors were identified as a known issue and fixed in version 1.10.0 per: slsa-framework/slsa-github-generator#3350
…trieving Rekor public keys (#280) **Requirements** - [ ] I have added test coverage for new or changed functionality - [ ] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [ ] I have validated my changes against all supported platform versions **Describe the solution you've provided** Provenance generation fails due to Rekor public key errors were identified as a known issue and fixed in version 1.10.0 per: slsa-framework/slsa-github-generator#3350
…trieving Rekor public keys (#82) **Requirements** - [ ] I have added test coverage for new or changed functionality - [ ] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [ ] I have validated my changes against all supported platform versions **Describe the solution you've provided** Provenance generation fails due to Rekor public key errors were identified as a known issue and fixed in version 1.10.0 per: slsa-framework/slsa-github-generator#3350
The "Generate builder" and "Run sigstore/cosign-installer" steps have started failing for my workflows. This used to work fine, not sure if it is just an intermittent error or something more fundamental:
Here's a build that worked 18 hours ago but is failing now (i.e. without any code changes): https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/runs/8339143012 (corresponding workflow)
Generate builder
error:Run sigstore/cosign-installer@6e04d228eb30da1757ee4e1dd75a0ec73a653e06
error:The text was updated successfully, but these errors were encountered: