fetchurl: don't prefer hashed mirrors by default

[winterqt]

Right now, when building any FOD that uses fetchurl (which is the majority of ours), tarballs.nixos.org will always be contacted before the actual URL. Given that tarballs.nixos.org mainly hosts the bootstrap tools, which already explicitly set it as the host to pull from, it doesn't make much sense to force every other fetchurl invocation to first reach out to tarballs.nixos.org.

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[winterqt]

@ofborg build tests.fetchurl

[philiptaron]

Is there a report or logs from the infra team we could use to track the positive impact on t.n.o of this PR?

[winterqt]

I doubt it (nor do I really think it’d be worth the time/effort to pull), but cc @mweinelt

[mweinelt]

We have some data that we used to grab from fastly, who handle the reverse proxying and caching for us.

Currently fetching that data is in limbo. We need to finish NixOS/infra#388 on the infra side to make this data available again.

[winterqt]

Objections to backporting? TBH I wouldn’t consider this a breaking change, as it’ll still fetch from t.n.o if it can’t reach the specified host (and if anything was relying on this behavior by putting a bogus/incorrect URL in, that’s a bug).

[winterqt]

Going to land now, but would appreciate some opinions on backporting. (@mweinelt said yes to me on Matrix, at least.)

[nixpkgs-ci]

Successfully created backport PR for release-24.11:

• [Backport release-24.11] fetchurl: don't prefer hashed mirrors by default #405808

[elpdt852]

@winterqt We hit this change internally and just wanted to share a data point. For some context, we host our internal Nix cache so we don't benefit from cache.nixos.org narinfo-style substitution.

Sometimes the contents of the URL changes in a way (say GitHub changes .patch formatting) that causes a hash mismatch, but a point-in-time copy is available in tarballs.nixos.org which actually hosts a significant amount of the FODs. I believe nix-infra or somewhere crawls FODs using the find-tarballs.nix and uploads them there.

After this change, we're left with either modifying the FOD hash or maintaining a patch reverting this change. In a way this was a breaking change for us, but I understand we may be a bespoke usecase.