Repository navigation
docs: replace the silent patch model with the monthly private patch cycle - #18
Merged
Merged
Conversation
aljo242
force-pushed
the
security/monthly-private-patch-cycle
branch
from
September 30, 2026 20:53
c44c34e to
f3fc9ea
Compare
aljo242
marked this pull request as ready for review
October 1, 2026 14:59
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
dianab-cl
approved these changes
Oct 1, 2026
…ycle Brings SECURITY.md in line with the agreed patching policy change. Every severity is patched privately in that month's private repository, shared with KYC'd downstream teams, and published with a full GHSA at the start of the next month. Drops the severity-based disclosure table, since severity no longer decides how or when a fix is published. Active exploitation still leaves the cycle and is handled as an incident.
Criticals go out on the repository's security mailing list; everything else is found by watching the private repo's -hotfix tags. This is what we already told Cronos when they asked on 2026-09-17, but the policy did not say it.
Drops the aside explaining why lower severities are not emailed, and the colloquial phrasing, to match the rest of the document.
The old wording attributed the ten days to moving a late critical into the next month's repository. Moving it actually pushes the public release out by a month; the ten days is the floor the three-day rule plus the freeze guarantees for any critical. Reworded so a chain planning around it gets the right number. Also states what the RFC is explicit about and the policy was not: the cycle is the same whether a vulnerability arrives by bug bounty, internal audit, or direct disclosure.
The rule read "not into a downstream codebase", which bans possession and collides with the replace-directive guidance two paragraphs down: a team that vendors would copy patch source into its own tree by following the policy. The rule is about distribution. A team with access can build however it needs to, vendoring included, and must not pass the source on to anyone else before the patch is public. Also says what happens to a replace directive after the private repository is deleted, which the policy described but never followed through on.
…ease Deleting it the moment its patches went public broke any later rebuild of the binary a team shipped from it: a validator building from source, CI on a release branch, a reproducible-build check. A two-week window gives teams time to move their replace directives to the public tags. The window holds nothing back, since every patch in a frozen repository is public before it starts. Re-invitation for the next month's repositories runs on its own schedule, so the liveness check on the collaborator list is unaffected.
aljo242
force-pushed
the
security/monthly-private-patch-cycle
branch
from
October 1, 2026 17:12
d0f21e4 to
01e5f7e
Compare
mattac21
approved these changes
Oct 1, 2026
| ### Disclosure Timeline | ||
| The private repositories are frozen for the last week of each month. During the | ||
| freeze no further patches are merged into that month's repositories. They are | ||
| merged into the next month's instead, which is why each month's set is created |
Contributor
There was a problem hiding this comment.
which is why each month's set is created seven days early
this looks like the first spot we reference this, but it reads like people already are aware of this, which reads awkwardly
| month's repositories is granted by fresh invitation on its own schedule, so the | ||
| retention does not extend anyone's access. | ||
|
|
||
| A vulnerability reported on August 12 and patched on August 15 therefore reaches |
Contributor
There was a problem hiding this comment.
Suggested change
| A vulnerability reported on August 12 and patched on August 15 therefore reaches | |
| As an example, a vulnerability reported on August 12 and patched on August 15 therefore reaches |
I was slightly confused when reading this paragraph as I didnt realize it was an example at first
aljo242
added a commit
that referenced
this pull request
Oct 1, 2026
The seven-days-early creation of the next month's repositories was written as a callback, but that sentence is the first time the policy mentions it. States it as new information and says what it is for. Marks the August walkthrough as an example, which was not obvious on a first read.
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
3 participants
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.
Replaces the silent patch model with the monthly private patch cycle. Every severity is patched privately, published with a full GHSA at the start of the next month.
Consequences for leaking private patch source are left unstated, pending the legal call on NDAs.