Follow-up from #1108 / PR #1110.
What exists now
docs/dev/releasing.md § Upgrading an install older than v1.19.1 documents the escape path for the population that predates the containerised verifier:
- v1.19.0 refuses a one-click upgrade unconditionally when
command -v cosign fails.
- v1.18.1 refuses when
cosign.pub is present and the binary is absent.
- The fix is to install the pinned cosign v2.6.3 on the host once, then retry — v3 satisfies
command -v and then fails the verify, because it removed the --tlog-upload / --insecure-ignore-tlog flags those releases pass.
What is missing
Those guards were read from the released pithead at each tag. The escape path itself has not been executed on a box actually running v1.18.1 or v1.19.0. The doc says so in the section, so nothing over-claims — but a documented recovery procedure that has never been run is exactly the kind of thing that turns out to have a second wall behind the first.
An upgrade is driven by the installed code, so this cannot be proven from a current checkout or from tier 1. It needs a real install at one of those versions.
Acceptance
On a disposable install at v1.18.1 and at v1.19.0, with no host cosign:
- The one-click upgrade refuses, with the message the released code carries.
- Installing the pinned cosign v2.6.3 clears the refusal.
- The upgrade then completes onto a release whose verifier is the container, and the host binary is unused from the next upgrade on.
- Confirm a cosign v3 binary satisfies the old
command -v guard and then fails the verify — if it does, the doc's "take v2.6.3, not the newest" warning is load-bearing and should be repeated in the v1.19.2 release notes.
Record what actually happened in releasing.md and drop the "not yet proven on a live install" note once it is.
Related
🤖 Generated with Claude Code
Follow-up from #1108 / PR #1110.
What exists now
docs/dev/releasing.md § Upgrading an install older than v1.19.1documents the escape path for the population that predates the containerised verifier:command -v cosignfails.cosign.pubis present and the binary is absent.command -vand then fails the verify, because it removed the--tlog-upload/--insecure-ignore-tlogflags those releases pass.What is missing
Those guards were read from the released
pitheadat each tag. The escape path itself has not been executed on a box actually running v1.18.1 or v1.19.0. The doc says so in the section, so nothing over-claims — but a documented recovery procedure that has never been run is exactly the kind of thing that turns out to have a second wall behind the first.An upgrade is driven by the installed code, so this cannot be proven from a current checkout or from tier 1. It needs a real install at one of those versions.
Acceptance
On a disposable install at v1.18.1 and at v1.19.0, with no host cosign:
command -vguard and then fails the verify — if it does, the doc's "take v2.6.3, not the newest" warning is load-bearing and should be repeated in the v1.19.2 release notes.Record what actually happened in
releasing.mdand drop the "not yet proven on a live install" note once it is.Related
release-smoke --upgradeasserts against the OLD install dir, so a successful upgrade reports as a failure. Worth fixing first if that harness is used to drive this.🤖 Generated with Claude Code