Security support window

View as Markdown

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

Version line	Security fixes
Latest minor of the current stable major	All security fixes
Earlier minors of the current stable major	None; upgrade to the latest minor
Earlier major	Until the successor stable major is released, as described under Major-line end of life

Registry Stack uses a roll-forward security model. Security fixes land on the current release line and ship in its latest minor or patch release. Registry Stack does not promise backports to an earlier minor.

The rest of the lifecycle policy is designed to make rolling forward cheap:

Within a major line, upgrades are backward compatible per the 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 documents the upgrade and revert boundary. Stable release acceptance requires the procedure to pass against the exact candidate.

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.

Major-line end of life

Registry Stack announces the end of support for a major line at least 90 days before the successor stable major is released. The announcement includes the exercised upgrade path. The old major remains supported until the successor stable major is released, then security maintenance moves to the successor’s latest minor.

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 check in the CI rust job, 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 in deny.toml with a review trigger; a newly published advisory fails CI until it is fixed or receives its own documented ignore.

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

This policy is stack-wide. This page supersedes the narrower statement in products/manifest/SECURITY.md that security fixes target the current main branch.
Pre-1.0 releases (v0.x) are technical releases for evaluation and pilots. They receive fixes only in the latest v0.x release, under the same roll-forward model.