Unreleased documentation. These pages follow the main branch and can change before the next release. For supported guidance, use v0.44.0.
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 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 |
For the independent Discovery pilot, support covers the Discovery version selected by the
current recommended Stack distribution and explicitly tested later patches on that same
major/minor line. Release and distribution notes name tested combinations; an arbitrary mix
of product versions is not a supported distribution. Discovery fixes can ship before the next
Stack release, under their own discovery/vX.Y.Z tag.
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:
- For products still on the Stack release train, a minor release removes a covered surface only
after deprecating it in an earlier minor, per the compatibility promise. Registry Evidence
and Registry Manifest have no migrated state, so moving to the fixed release needs no migration
step for them. Base
Registry Engine, Casework, Scheduling, and Messaging each own migrated PostgreSQL state;
moving to the fixed release for one of them can require running the migration command its
release notes name (
bregctl apply,caseworkctl apply,schedulingctl apply, ormessagingctl apply). Before 1.0, a release reads only the state its immediate predecessor wrote, so upgrade one release at a time.v0.40.0is the exception: it does not upgradev0.39.0state in place, and its release notes have you apply it to new databases, as the upgrade runbook describes. - Patch releases contain fixes only, so a security patch is a minimal, low-risk step.
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
Section titled “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
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 rules.
- 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 applies to the recommended distribution and its tested Discovery patch variants.
Independently released Discovery uses its own version line. 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.
Cookies on Registry Stack
We use optional cookies to understand how you use the main Registry Stack website and this documentation. If you contact us, we may link this activity to your enquiry. You can change your choice at any time. Read the privacy policy.
Your browser asks sites not to track you, so optional tracking stays off.
We could not use or save that choice. Optional tracking remains off.