How do you prepare an embargoed security fix without the public repository revealing it?

## Goal Between the report landing and the release going out, the fix must exist, be reviewed, be tested on every line you intend to ship it on, and be invisible to anyone outside a small circle. Those pull in opposite directions, and most of the craft here is managing that tension. ## Where the work happens The practical pattern is a **private fork or private mirror** of the repository, created for this issue, with an explicit access list. Many forges provide a private workspace attached to a draft advisory for exactly this; a self-hosted private mirror works equally well. What matters is not the mechanism but two properties: the code is not publicly readable, and the set of people who can read it is chosen per issue rather than inherited from a standing group. **Branch from the released tag, not from the mainline.** A fix built on top of months of unreleased mainline changes is hard to backport, hard to review under pressure, and hard to ship as a patch release that consumers can take without also taking unrelated behaviour changes. Branching from the tag keeps the change minimal and gives you a base that already resembles each supported line. ## Designing what the public will eventually see Decide the public shape of the change *while you write it*, because you only get one chance to land it: - **One squashed commit** at release time, rather than the twelve exploratory commits that actually produced it. Intermediate commits narrate the discovery — a failed fix, a widened check, a revert — and that narration is a tutorial on the flaw. - **A commit message that is accurate but not instructional.** "Harden input validation in the configuration reader" before release; the advisory carries the detail afterwards. Deliberately misleading messages are a different thing and corrode trust — aim for uninformative, not false. - **No public ticket reference.** Track the work in the private space. A public issue whose title is the vulnerability, closed by the commit, defeats everything else you did. - **A regression test that does not double as a proof-of-concept.** Test the invariant ("unknown types are rejected") rather than shipping the crafted payload that exercises the bug. Where that is impossible, land the test with or after the release, not ahead of it. Take a framework fixing a deserialization flaw as the worked case. The public repository is mirrored by bots within seconds of a push, so the discipline is not theatre: a single commit introducing a class allow-list, with a test that feeds it a gadget chain, is a complete attack write-up for an anonymous observer who has no access to anything else you own. ## The leaks that survive a private branch People get the branch right and lose on the periphery: - **CI and build logs.** A build triggered from the private branch may publish logs, test names or artifacts to a place the public can read. Route embargoed builds to a private runner and a private log sink. - **Pre-release artifacts.** A candidate build pushed to a publicly readable pre-release or staging channel is downloadable and diffable. - **Dependency changes.** Bumping an upstream library whose own release notes name the flaw announces it for you. - **Documentation and translation pipelines.** Strings queued for translation, or docs rebuilt from the private branch, have escaped more than one embargo. - **Third-party notifications.** Chat integrations, mail relays and project-management syncs attached to the fork may fan the diff out to a wider audience than the fork's access list. ## Who gets to see it The circle should be as small as the work allows — and the work usually needs more people than the person writing the patch: a reviewer with real context, someone to build and test each supported line, sometimes the reporter, who is often the only person able to confirm the fix actually closes the flaw they found. Confirming a fix with the reporter is normal and valuable; send them a patch or a build rather than granting repository access. The failure mode is a *standing* security repository whose read list has quietly grown to include everyone who ever needed it — contractors, former team members, an entire engineering group. Fifty people with read access is not an embargo; it is a press release with a delay. Prefer per-issue spaces with named, time-boxed access, keep the ability to *read the fix* separate from the ability to *test a build* (many testers need only the binary), and be able to answer afterwards who could see it. If the fix leaks, that list is the investigation. ## A note on scope creep Under embargo the temptation is to fix the whole class of problem, refactor the offending module, or slip in unrelated cleanups because the branch is open anyway. Resist it. A larger diff is harder to review with few reviewers, harder to backport, more likely to break consumers taking an urgent patch release, and — because it touches more code — often more revealing rather than less.