nixos: add script to automatically update nix-fallback-paths

[Mic92]

This replicates
https://github.com/NixOS/nix/blob/68ba6ff4709d936c1a714de35da08f8ed354c710/maintainers/upload-release.pl#L241

however it can be run by everyone and not just eelco with s3 access. We often have the issue that this file goes out-of-date, so having this script in nixpkgs, now ever nixpkgs contributor can update this file.

This allows to make security releases faster without having privileged access to avoid situations as in https://discourse.nixos.org/t/nar-unpacking-vulnerability-post-mortem/52301

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Mic92]

With this change ever nix maintainer who can create tags on github, could also do a release in nixpkgs.

[edolstra]

Not sure I understand the use case. The only reason for updating nix-fallback-paths is when there is a new release, and those all include a fallback-paths.nix file.

If the issue is that not everybody can run the release script, then that's what we should fix - we shouldn't have multiple divergent release processes. (If I understand this PR correctly, it would result in releases that are tagged in Git but that don't exist on https://releases.nixos.org/ and wouldn't appear on the Nix download page.)

[Mic92]

The issue with vendoring to nix releases only is though that we not regularly can rebuild those fallback paths. i.e. let's say we would some vulnerability in curl or openssl. Nix upstream doesn't really track the security of any of its libraries and makes releases based on that. So I am wondering if we should instead have our own release builds in nixpkgs instead that can be bumped independently of nix releases being made.

[roberth]

While I do agree with Eelco about having one release process, I think we can still use NixOS/nix#11565 to make the process easier to understand, and easier to check, and easier to use or abuse in a pinch. It just needs to replace some perl code by a simpler download.