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 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 and Provide a binary cache for builds · Issue #68 · NixOS/ofborg · GitHub.
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/, 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).