# Transforming global software distribution with Nixpkgs

**URL:** https://discourse.nixosstag.fcio.net/t/transforming-global-software-distribution-with-nixpkgs/64989
**Category:** Announcements
**Created:** [May 30, 2025, 4:13pm UTC](https://discourse.nixosstag.fcio.net/t/transforming-global-software-distribution-with-nixpkgs/64989 "2025-05-30T16:13:56Z")
**Posts on this page:** 1
**Showing post:** 15

<div class="post-metadata">

### Author: ![tobiasBora](https://discourse.nixosstag.fcio.net/letter_avatar_proxy/v4/letter/t/9de0a6/32.png) [@tobiasBora](https://discourse.nixosstag.fcio.net/u/tobiasBora)
#### Post date: [June 25, 2025, 2:46pm UTC](https://discourse.nixosstag.fcio.net/t/transforming-global-software-distribution-with-nixpkgs/64989/15 "2025-06-25T14:46:21Z")

</div>

I’m not sure if this is what you refer to as “Assert reproducibility of Nixpkgs source retrieval”, but in case, this seems like a great place to mention (thanks @RaitoBezarius for pointing me here) this CVE I raised a year ago [NVD - CVE-2024-36050](https://nvd.nist.gov/vuln/detail/CVE-2024-36050) that I also discussed with the security team (I had no recent answer after I said I would create the CVE), and it is discussed in [re-fetch source when url changes · Issue #969 · NixOS/nix · GitHub](https://github.com/NixOS/nix/issues/969#issuecomment-2083382876) and [Provide a binary cache for builds · Issue #68 · NixOS/ofborg · GitHub](https://github.com/NixOS/ofborg/issues/68#issuecomment-2085327052).

This describes an attack that is almost impossible to detect (for a PR reviewer) allowing a malicious PR to inject arbitrarily malicious code in basically any software, by simply changing the hash. The attack is very easy to run and can have devastating effects (trapdoor, viruses…). Yet, as far as I know, one year later, it is still effective, even if I proposed some proposals for potential fixes (the best fixes are not completely trivial as they require nix & caches to also maintain a list of **verified** couple hash/url, but as far as I see this is the only really robust solution to this issue).

@RaitoBezarius mentionned [https://fod-oracle.org/](https://fod-oracle.org/), but this is a very hacky & expensive way to check nixpkgs using external tools, and would not apply outside of nixpkgs. A cleaner solution would require directly nix & caches to maintain (and distribute) a list of verified `(hash, url)` tupples, but this require some transformation on the nix APIs, but at least it is clean and should be reasonably efficient (i.e. avoid re-downloading all sources when fetching an untrusted derivation).

---

_[View the full topic](https://discourse.nixosstag.fcio.net/t/transforming-global-software-distribution-with-nixpkgs/64989)._