Repository navigation
Change default CLI upload type to hashedrekord - #2885
Merged
Merged
Conversation
Contributor
Author
|
Verify this works with: |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2885 +/- ##
===========================================
- Coverage 66.46% 27.72% -38.74%
===========================================
Files 92 192 +100
Lines 9258 20362 +11104
===========================================
- Hits 6153 5646 -507
- Misses 2359 13846 +11487
- Partials 746 870 +124
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Hayden-IO
force-pushed
the
change-rekor-cli-default
branch
7 times, most recently
from
July 22, 2026 20:07
8b1b3dd to
75b14a6
Compare
Hayden-IO
marked this pull request as draft
July 22, 2026 20:07
Hayden-IO
marked this pull request as ready for review
July 22, 2026 20:32
Contributor
Author
|
This is finally ready, had to update a bunch of e2e tests. |
bobcallaway
reviewed
Aug 3, 2026
This change sets the default `--type` flag to `hashedrekord` in rekor-cli, along with changing the default `--pkiFormat` flag to x509 (which is certificates and public keys). This is done in a backwards compatible way, in that a client can continue to pass an artifact via --artifact and it will automatically be hashed if the type is hashedrekord. While the PKI flag change is a breaking change, I doubt anyone was using pgp, which was the default. Signed-off-by: Hayden <8418760+Hayden-IO@users.noreply.github.com>
Hayden-IO
force-pushed
the
change-rekor-cli-default
branch
from
August 3, 2026 16:23
75b14a6 to
e1c6a90
Compare
bobcallaway
approved these changes
Aug 3, 2026
bobcallaway
left a comment
bobcallaway
left a comment
Member
There was a problem hiding this comment.
we'll want to doc this in the next changelog
stgrace
pushed a commit
to stgrace/rekor
that referenced
this pull request
Aug 22, 2026
This change sets the default `--type` flag to `hashedrekord` in rekor-cli, along with changing the default `--pkiFormat` flag to x509 (which is certificates and public keys). This is done in a backwards compatible way, in that a client can continue to pass an artifact via --artifact and it will automatically be hashed if the type is hashedrekord. While the PKI flag change is a breaking change, I doubt anyone was using pgp, which was the default. Signed-off-by: Hayden <8418760+Hayden-IO@users.noreply.github.com>
kdacosta0
added a commit
to securesign/sigstore-e2e
that referenced
this pull request
Oct 7, 2026
Both surfaced once the suite started downloading the release under test instead of falling back to 1.4.2. rekor-cli: upstream changed the default upload type from rekord to hashedrekord (sigstore/rekor#2885), so `rekor-cli get` returns the entry under HashedRekordObj. The test only read RekordObj, ended up with an empty hash, and passed ":" to --sha. Accept either shape, and fail with a clear message if neither is present. gitsign: 1.5.0 enables the sigstore-go verification path by default, which gitsign's own comment marks as experimental and claims leaves "the default behavior unchanged". That path loads CT log keys via cosign.GetCTLogPubs rather than the trusted root `gitsign initialize` fetched from the cluster, falls back to an embedded public-good root that expired 2025-08-19, and verification fails. Pin the legacy path for now; this is a workaround, not a fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kdacosta0
added a commit
to securesign/sigstore-e2e
that referenced
this pull request
Oct 7, 2026
A content gateway file URL never serves the archive. It redirects to an HTML interstitial page that carries the real CDN location in its tcDownloadURL query parameter, so dereferencing it with a redirect-following client yields ~155 KB of HTML and extraction fails with "gzip: invalid header". The openshift strategy treated that failure as a cue to retry against a hardcoded RHTAS 1.4.2, resolving the CDN link only for that older release. Because the first attempt could never succeed, the fallback fired on every run: every CLI published in 1.4.2 was validated at 1.4.2 regardless of the version under test, while the suite reported green. Confirmed against a 1.5.0 cluster, where cosign reported GitCommit 5e8a5593 (the 1.4.2 build) rather than 1.5.0's 608114e8. tufcli, which 1.4.2 never shipped, fell through a second fallback to `go install`, which resolves the only tag in the repo (v0.0.1-rc1, 45 commits behind main) and builds without the piv tag, so the published artifact was never executed at all. Resolve the CDN link up front for content gateway URLs and drop the version rewrite. The version now comes solely from the ConsoleCLIDownload resource the operator deploys, so whatever is on the cluster is what gets tested, and a release that does not publish a usable binary fails the suite instead of quietly substituting another one. The private go install fallback in NewTufcli goes with it; CLI_STRATEGY=goinstall remains available when building from source is the intent. Also: - rekor-cli upstream changed the default upload type from rekord to hashedrekord (sigstore/rekor#2885), so `rekor-cli get` returns the entry under HashedRekordObj. The test only read RekordObj, ended up with an empty hash and passed ":" to --sha. Accept either shape. - The e2e job pinned CLI binaries to 1.4.2 while building the operator from secure-sign-operator main. Bump it to 1.5.0, make it overridable per run, and write down when it should move. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kdacosta0
added a commit
to securesign/sigstore-e2e
that referenced
this pull request
Oct 7, 2026
A content gateway file URL never serves the archive. It redirects to an HTML interstitial page that carries the real CDN location in its tcDownloadURL query parameter, so dereferencing it with a redirect-following client yields ~155 KB of HTML and extraction fails with "gzip: invalid header". The openshift strategy treated that failure as a cue to retry against a hardcoded RHTAS 1.4.2, resolving the CDN link only for that older release. Because the first attempt could never succeed, the fallback fired on every run: every CLI published in 1.4.2 was validated at 1.4.2 regardless of the version under test, while the suite reported green. Confirmed against a 1.5.0 cluster, where cosign reported GitCommit 5e8a5593 (the 1.4.2 build) rather than 1.5.0's 608114e8. tufcli, which 1.4.2 never shipped, fell through a second fallback to `go install`, which resolves the only tag in the repo (v0.0.1-rc1, 45 commits behind main) and builds without the piv tag, so the published artifact was never executed at all. Resolve the CDN link up front for content gateway URLs and drop the version rewrite. The version now comes solely from the ConsoleCLIDownload resource the operator deploys, so whatever is on the cluster is what gets tested, and a release that does not publish a usable binary fails the suite instead of quietly substituting another one. The private go install fallback in NewTufcli goes with it; CLI_STRATEGY=goinstall remains available when building from source is the intent. Also: - rekor-cli upstream changed the default upload type from rekord to hashedrekord (sigstore/rekor#2885), so `rekor-cli get` returns the entry under HashedRekordObj. The test only read RekordObj, ended up with an empty hash and passed ":" to --sha. Accept either shape. - The e2e job pinned CLI binaries to 1.4.2 while building the operator from secure-sign-operator main, validating current services against the previous release's CLIs. Bump the pin to 1.5.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This change sets the default
--typeflag tohashedrekordin rekor-cli, along with changing the default--pki-formatflag tox509(which is certificates and public keys).This is done in a backwards compatible way, in that a client can continue to pass an artifact via --artifact and it will automatically be hashed if the type is hashedrekord.
While the PKI flag change is a breaking change, I doubt anyone was using pgp, which was the default.
Release Note
Documentation