Preview release.These docs are a work in progress. Pages are still being written, links may break, and structure may shift without notice. Treat everything here as a draft and report issues onGitHub.
This page states which Registry Stack versions receive security fixes and how those fixes reach a deployment. It complements the vulnerability reporting process, which covers how to report, what is in scope, and how reports are acknowledged.
Supported versions
Section titled “Supported versions”| Version line | Security fixes |
|---|---|
| Latest release line (highest released minor of the highest major) | All security fixes |
| Earlier releases | None |
Registry Stack’s roll-forward model is a draft policy
(GH#203): security fixes land on main and ship in the next release of the latest line, with
no long-term support branches and no backports to earlier minor lines.
The rest of the lifecycle policy is designed to make rolling forward cheap:
- Within a major line, upgrades are backward compatible per the draft compatibility promise, so moving to the fixed release does not require migration work beyond reading the release notes.
- Patch releases contain fixes only, so a security patch is a minimal, low-risk step.
- The upgrade procedure is documented and exercised, including the revert path if a fixed release misbehaves in your environment.
What this means for an institution: plan to apply patch releases of your deployed line promptly. A deployment pinned to an old minor does not receive fixes in place; the fix is always in a newer release.
How fixes are delivered
Section titled “How fixes are delivered”- A security fix ships as a release with signed artifacts and provenance, verifiable as documented in SECURITY.md.
- Release notes identify security-relevant changes. When a fix required tightening covered surface, the notes say so explicitly, per the security exception in the deprecation policy.
- Dependency advisories are enforced through
cargo deny checkin the CIrustjob, which runs on every push that touches Rust code (the job is path-filtered). An advisory without an upstream fix carries a scoped, documented ignore indeny.tomlwith a review trigger; a newly published advisory fails CI until it is fixed or receives its own documented ignore.
Reporting and acknowledgment
Section titled “Reporting and acknowledgment”Report suspected vulnerabilities privately through GitHub Security Advisories, as described in Report a vulnerability. Private reports are acknowledged within 5 business days.
Scope notes
Section titled “Scope notes”- This policy is stack-wide. This page supersedes the narrower statement in
products/manifest/SECURITY.mdthat security fixes target the currentmainbranch. - Pre-1.0 releases (
v0.x) are technical releases for evaluation and pilots. They receive fixes only in the latestv0.xrelease, under the same roll-forward model.