Disable cosign's signing config so sidecar signatures work - #395
Merged
Conversation
#393 diagnosed the v0.3.1 signing failure as cosign v3's bundle-format default and set `--new-bundle-format=false`. That was wrong, and the re-dispatched release failed at the same step on every leg that reached it: Error: must provide --new-bundle-format or --bundle where applicable with --signing-config or --use-signing-config The gate is signcommon/common.go at v3.0.6, lines 660-661: if (useSigningConfig || signingConfigPath != "") && !newBundleFormat && bundlePath == "" { return fmt.Errorf("must provide --new-bundle-format or --bundle ...") It needs both halves false. `--new-bundle-format=false` satisfies one and leaves `useSigningConfig` standing, which defaults to TRUE in v3 (options/signblob.go:111). So the real v3 change behind this was the signing config defaulting on, not the bundle format. Add `--use-signing-config=false` to both sign steps. It is the only gate that applies: the neighbouring checks at :649 (service URLs) and :656 (tlog-upload) also require a signing config, and the checks at :693-708 all require newBundleFormat true, which stays false here. `--new-bundle-format=false` is kept on its own account -- with it true, cosign writes a bundle to --bundle, unset here, instead of the detached files. Sidecar output is reachable with both off: sign_blob.go closes its `if ko.BundlePath != ""` block at line 229, before the outputSignature (231) and outputCertificate (250) writes. Read as code, not inferred from a grep -- doing exactly that is how #393 shipped wrong. Also rewrites both step comments, which stated the #393 diagnosis as fact and would otherwise have preserved it in the file. Not verified by CI: no CI job runs release.yml. The proof is a dispatch.
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
1 participant
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.
See commit message. In short: #393's diagnosis was wrong — the v3 change that broke signing is
--use-signing-configdefaulting to true, not the bundle format. The gate atsigncommon/common.go:660needs both halves false; #393 set only one, so every leg that reached the signing step failed withmust provide --new-bundle-format or --bundle ... with --signing-config or --use-signing-config.This adds
--use-signing-config=falseto both sign steps and rewrites the comments, which had recorded the wrong diagnosis as fact.Sidecar output confirmed reachable by reading
sign_blob.goas code: theif ko.BundlePath != ""block closes at line 229, before theoutputSignature(231) andoutputCertificate(250) writes. Reading grep hits instead of code is how #393 shipped wrong.CI cannot verify this. No CI job runs
release.yml. The proof is a dispatch against v0.3.1.