maintainers: add checklist for security releases

maintainers/README.md

@@ -63,6 +63,9 @@ Team meetings are generally open to anyone interested.
 We can make exceptions to discuss sensitive issues, such as security incidents or people matters.
 Contact any team member to get a calendar invite for reminders and updates.
 
+> [!IMPORTANT]
+> [Handling security reports](./security-reports.md) always takes priority.
+
 ## Project board protocol
 
 The team uses a [GitHub project board](https://github.com/orgs/NixOS/projects/19/views/1) for tracking its work.

maintainers/release-process.md

@@ -15,7 +15,7 @@ release:
 
 * (Optionally) Updated `fallback-paths.nix` in Nixpkgs
 
-* An updated manual on https://nixos.org/manual/nix/stable/
+* An updated manual on https://nix.dev/manual/nix/latest/
 
 ## Creating a new release from the `master` branch
 
@@ -194,8 +194,58 @@ release:
 
 * Bump the version number of the release branch as above (e.g. to
   `2.12.2`).
-  
+
 ## Recovering from mistakes
 
 `upload-release.pl` should be idempotent. For instance a wrong `IS_LATEST` value can be fixed that way, by running the script on the actual latest release.
 
+## Security releases
+
+> See also the instructions for [handling security reports](./security-reports.md).
+
+Once a security fix is ready for merging:
+
+1. Summarize *all* past communication in the report.
+
+1. Request a CVE in the [GitHub security advisory](https://github.com/NixOS/nix/security/advisories) for the security fix.
+
+1. Notify all collaborators on the advisory with a timeline for the release.
+
+1. Merge the fix. Publish the advisory.
+
+1. [Make point releases](#creating-point-releases) for all affected versions.
+
+1. Update the affected Nix releases in Nixpkgs to the patched version.
+
+   For each Nix release, change the `version = ` strings and run
+
+   ```shell-session
+   nix-build -A nixVersions.nix_<major>_<minor>
+   ```
+
+   to get the correct hash for the `hash =` field.
+
+1. Once the release is built by Hydra, update fallback paths.
+
+   For the Nix release `${version}` shipped with Nixpkgs, run:
+
+   ```shell-session
+   curl https://releases.nixos.org/nix/nix-${version}/fallback-paths.nix > nixos/modules/installer/tools/nix-fallback-paths.nix
+   ```
+
+   Starting with Nixpkgs 24.11, there is an automatic check that fallback paths with Nix binaries match the Nix release shipped with Nixpkgs.
+
+1. Backport the updates to the two most recent stable releases of Nixpkgs.
+
+   Add `backport release-<version>` labels, which will trigger GitHub Actions to attempt automatic backports.
+
+1. Once the pull request against `master` lands on `nixpkgs-unstable`, post a Discourse announcement with
+
+   - Links to the CVE and GitHub security advisory
+   - A description of the vulnerability and its fix
+   - Credits to the reporters of the vulnerability and contributors of the fix
+   - A list of affected and patched Nix releases
+   - Instructions for updating
+   - A link to the [pull request tracker](https://nixpk.gs/pr-tracker.html) to follow when the patched Nix versions will appear on the various release channels
+
+   Check [past announcements](https://discourse.nixos.org/search?expanded=true&q=Security%20fix%20in%3Atitle%20order%3Alatest_topic) for reference.

maintainers/security-reports.md

@@ -0,0 +1,25 @@
+# Handling security reports
+
+Reports can be expected to be submitted following the [security policy](https://github.com/NixOS/nix/security/policy), but may reach maintainers on various other channels.
+
+In case a vulnerability is reported:
+
+1. [Create a GitHub security advisory](https://github.com/NixOS/nix/security/advisories/new)
+
+   > [!IMPORTANT]
+   > Add the reporter as a collaborator so they get notified of all activities.
+
+   Note deadlines if applicable.
+
+1. Establish a private communication channel (e.g. a Matrix room) with the reporter and all Nix maintainers.
+
+1. Communicate with the reporter which team members are assigned and when they are available.
+
+1. Consider which immediate preliminary measures should be taken before working on a fix.
+
+1. Prioritize fixing the security issue over ongoing work.
+
+1. Keep everyone involved up to date on progress and the estimated timeline for releasing the fix.
+
+> See also the instructions for [security releases](./release-process.md#security-releases).
+