Nix Release Process: Point Releases, Mistake Recovery, and Security Releases

* Post an [announcement on Discourse](https://discourse.nixos.org/c/announcements/8), including the contents of `rl-$VERSION.md`. ## Creating a point release * Checkout. ```console $ git checkout XX.YY-maintenance ``` * Determine the next patch version. ```console $ export VERSION=XX.YY.ZZ ``` * Update release notes. ```console $ ./maintainers/release-notes ``` * Push. ```console $ git push ``` * Wait for the desired evaluation of the maintenance jobset to finish building. * Run ```console $ IS_LATEST=1 ./maintainers/upload-release.pl <EVAL-ID> ``` Omit `IS_LATEST=1` when creating a point release that is not on the most recent stable branch. This prevents `nixos.org` to going back to an older 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.

This document outlines the procedures for creating a point release, which involves checking out the maintenance branch, determining the patch version, updating release notes, pushing changes, waiting for jobset evaluation, and finally uploading the release artifacts using `upload-release.pl`, with careful consideration of the `IS_LATEST` flag. It also briefly mentions that `upload-release.pl` is idempotent, allowing for recovery from certain mistakes. A significant portion details the process for security releases, including handling security reports, requesting CVEs, notifying collaborators, merging fixes, publishing advisories, making point releases for all affected versions, updating Nix versions within Nixpkgs, updating fallback paths, backporting fixes to stable Nixpkgs releases, and posting a comprehensive Discourse announcement.