## Problem/motivation This is related to, but separate from, https://git.drupalcode.org/project/drupalorg/-/work_items/3607065. I may have missed some things. This is just a first draft. There are numerous aspects of the core security release process that make it time-consuming, frustrating, and risky. To borrow a phrase, core security releases are "Complex or highly specific (multi-step, unintuitive process with high number of dependencies)". 1. The matrix of possible changesets that must be reviewed, have signoffs, have passing tests, be available in backport versions with and without tests, be committed, and included in a tag, is massive. - The November 2025 window (before the CVE tsunami) required handling 39 separate changesets -- an all-time maximum at the time that, when combined with an upstream update, resulted in the releases not being available until after 23:00 UTC (well after the scheduled window). - Theroetically, a core window with 6 SAs on the 7 currently maintained branches could require that up to 86 changesets be managed for the release. - If an upstream dependency also had a release (very common at present), this number increases to up to 94 separate changesets that can't even be staged until the upstream release is published (often a mere few hours before the window).
 2. Following a policy adopted in 2011 before Drupal had a concept of semver, security releases are branched off the last tag rather than made on top of the last commits. However, pipelines run againsr HEAD. This means that occasionally the security release has critical bugs or test failures not present in the branch tip, or merge conflicts with the branch tip, or requires fixes present in HEAD but not in the previous tag, which leads to another potential merge conflict that needs to be managed.
 3. The [core security tagging script](https://github.com/xjm/drupal_core_release/blob/main/sec.sh) is written and maintained by a couple of past and present core release managers (plus larowlan). - The script handles the complex problem of tagging N SAs on X branches, including both the above branching workflow and properly formatting the commit messages with the SA number and the contributors for each SA. - However, it is fragile, ugly, lacks test coverage, and does not handle merge conflicts well. - It is also built around the old s.d.o workflow of downloading patches to disk.
 4. In order to stage the release in advance, core commits must be frozen for three reasons: - We need a stable target for the SA fixes themselves, to ensure they don't encounter regressions or commit conflicts at the last minute. - Fast-forward merges are not allowed on the protected branches, for good reason. This means that staged tags cannot be easily rebased on top of new commits in HEAD, because the hashes don't match on the lockfile, in git, etc. - Every commit pushed to core triggers a packaging job immediately, which happens before any tagged releases are saved and queued. This means that even commits on `main` have to pause well before the window in order to let the packaging queue clear. 5. If another committer breaks the freeze, the whole release has to be restaged.
 6. Currently, it is impossible to package core releases in private, even though some of the steps theoretically do not require the production codebase or external services. This combined with the above packaging process means commits can be in the public source code for 1.5-2.5h before the releases are all available for installation.
 7. The above packaging process means we push the tags before the branch tips with the full git history containing them, which universally leads to confusion, along with occasional merge conflicts and the odd regression or two.
 8. The above also means that we can't/don't stage or public fixes or tags on the forward branches (for e.g. a hypothetical 12.0.0-beta3, 11.5.0-beta2, etc.). Instead, the release manager has to wait around for the release window to be done and there to be evidence that there are not regressions, and only then can begin the hour-plus-long process of packaging the forward fixes for the SAs.
 9. In previous years, the above process happened for fewer branches, 2-4 times a year. With the current rate of security reports and CVEs, they pretty much must happen monthly to have any chance of keeping pace with the backlog.
 10. The above disruption also means that upstream projects are issuing far more CVEs, which increases the chances that Drupal will need to deal with updates for these dependencies, or coordinate disclosure with them. Both factors make this complex process more difficult.
 11. Release management funding is at only 45% of its 2022 levels. Funding for other critical committer roles has fallen even further, which means that those same release managers are also doing a lot of the work reviewing core RTBCs. 
 12. Contribution records are not available until after the SA is published. ## Proposed resolution There are many, many different fronts on which we must tackle this problem, including process changes, tooling changes, and deployment workflow changes. Improving packaging times is only part of it; properly funding critical security and maintenance roles is part of it; simplifying core processes and reducing support requirements are part of it. Separate discussions exist for those topics and may eventually be collected in the related issues here. However, many of the improvements we need for a sustainable core security release process involve changes to tooling, packaging, deployment, etc. The ideal workflow would go something like this: 24-48h the window: 1. Core security contributors add SA credits in an unpublished contribution record linked to the unpublished SA. 2. An SA ID is assigned to the SA, e.g. SA-CORE-2026-057. 3. All the SAs for the window are added to a GitLab milestone for it. 4. **An enforced commit freeze happens on the public repo** that can be unfrozen in emergency by a committer or the DA, on all branches to be staged (typically excluding main). (This might need to move after the tagging/node creation step for it to be automated and dependent on asking committers while the tagging is in the process of being staged.) 5. Automated tooling squash-commits the MRs from each branch for each SA, in order, with the correct contributor list format as per the contribution record commit message. (**In the current workflow, this would be a branch off the last tag and merge back**, but we are discussing dropping that requirement.) 6. Automated tooling tags all the tags using commands and scripts that are maintained in core, with test coverage. 7. The above are staged on the source branches (not feature branches) in a canonical issue fork for the milestone. 8. Unpublished release nodes are associated with the tags and the drafted release notes and metadata. 9. A partial packaging process begins, performing all the steps that can be done in private (like the subtree splits etc.) Right before the window: Final review happens on the staged tags, commit logs, committed changesets, release notes, SAs, etc. During the window: 1. The tags are merged from the private repo and then pushed to origin. 2. The tags being present in the public branch enables or even automatically triggers the final packaging steps on the release nodes. 3. **Final packaging job steps run in parallel.** 4. **Release managers have control of the packaging queue, can prioritize, kill, or re-run jobs.** 5. Release node packaging jobs are prioritized *before* the packaging jobs for the accompanying branch tips so there is no fussing around with tags seemingly orphaned from the commit history and missing post-merge commits in origin. 6. Final checks are performed, and the releases and SAs are published at the agreed moment. 7. Contribution records are filled and saved. The above workflow also has significant advantages for contrib: - It solves the problem of commits being public in the project's repo disclosing the vulnerability sometimes an entire day before a release is available (and occasionally weeks before the release is available when disclosure/release creation is not coordinated properly). - It solves the problem of the Security Team having to do many last-minute checks to see if the maintainers did everything they were supposed to. If there's any missing requirements, there's no release and it waits til next window. For contrib to work nicely, we'd need to potentially consider some sort of one-click publish to push tags to origin, because we don't want to wait on maintainers during the window itself. (We also for sure don't want to have Security Team members having to mess around with manually merging 40+ tags to their local on 30 projects and pushing them to the public repo.) ## Remaining tasks Much things. - [ ] ... ### Related issues - [ ] [Drop branching strategy based on previous tag](https://www.drupal.org/project/drupal/issues/3610860) - [ ] [Packaging performance and scalability](https://git.drupalcode.org/project/drupalorg/-/work_items/3607065) ## User interface changes Probably. ## API changes Probably. ## Data model changes Probably.