fix(cryptify): release the stranded security fixes as 0.1.28 - #279
Open
rubenhensen wants to merge 1 commit into
Open
fix(cryptify): release the stranded security fixes as 0.1.28#279rubenhensen wants to merge 1 commit into
rubenhensen wants to merge 1 commit into
Conversation
cryptify's CHANGELOG carried two hand-written bullets under `## [Unreleased]`, one of them citing GHSA-5rhx-xgvv-h78h. release-plz inserts each new version section *below* that heading, so bullets written there are never folded into a release; they sit above the newest version undated, forever. Both describe 8531b28 (2026-07-06), which is real, merged and shipped in no release. They were not alone. cryptify's last release is v0.1.27 (2026-05-16) and 31 commits have merged since, so the advisory fix plus a RUSTSEC lettre bump, the metrics bearer token and the 5xx body leak fix have all been sitting unreleased for two and a half months. The [Unreleased] section documented two of them. This writes a dated 0.1.28 entry covering the actual backlog, generated from the commit subjects rather than by hand, and bumps the manifest so release-plz's `release` job tags it. Hand-bumping the version is normally release-plz's job. It cannot do it here: it keys off commits touching `cryptify/`, and the imported history carries root-level paths, so it sees no cryptify changes and proposes no bump. Without a manual bump nothing ever releases these. Merging this cuts cryptify 0.1.28 and publishes the advisory fix in a dated release note. Refs #255
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.
cryptify's
CHANGELOG.mdcarried two hand-written bullets under## [Unreleased], one of them citing GHSA-5rhx-xgvv-h78h:release-plz inserts each new version section below that heading, so bullets written there are never folded into the release that follows. They sit above the newest version, undated, indefinitely. CLAUDE.md documents this trap; these two were already in it.
Both describe
8531b28(2026-07-06). I checked the code rather than trusting the note:cryptify_tokens_matchusessubtle::ConstantTimeEq, and there is ausage_rejects_unauthenticated_requesttest. The fixes are real and merged.They were not alone
cryptify's last release is v0.1.27, 2026-05-16, and 31 commits have merged since. The
[Unreleased]section documented two of them. Also sitting unreleased for two and a half months:lettre0.11.21 → 0.11.22 (RUSTSEC-2026-0141)/metricswhen configuredWhat this does
Writes a dated
0.1.28section covering the real backlog, derived from the commit subjects rather than hand-summarised, and bumpscryptify/Cargo.tomlso release-plz'sreleasejob tags it.Merging this cuts cryptify 0.1.28 and publishes the advisory fix in a dated release note.
On hand-bumping the version
Normally release-plz owns version numbers and a PR should not set them. It cannot do it here. release-plz decides a package changed by looking for commits touching
cryptify/, and the imported history carries root-level paths (src/main.rs, notcryptify/src/main.rs), so it sees no cryptify changes and proposes no bump. #278 confirms this: it touches pg-cli and pg-pkg only, both before and after the history graft.So without a manual bump, nothing ever releases these. After this lands, release-plz has a
cryptify-v0.1.28tag to measure from and normal service resumes.Verification
cargo test --manifest-path cryptify/Cargo.toml --all-targets→ 157 passed. Workspace resolves; the only lockfile change is cryptify's own version.