In the last few days, thousands of packages have been compromised in the Arch User Repository (AUR). After an initial round grew to over 1,500 compromised packages, another round of more sophisticated malware claimed yet more packages. This is a devastating development and we extend major #hugops to the Arch security team tasked with cleaning it up.
Some people have the perception that Nixpkgs is immune to this attack, but we need to be frank with ourselves: it isn’t. Nobody will be rewarded for hubris. Nixpkgs’s hundreds of maintainers are all empowered to merge their own PRs with absolutely no review, and this privilege isn’t reserved solely for emergency situations—it’s used with such regularity by said maintainers that it could be described as standard operating procedure.
I believe that there is an urgent and imminent risk of a similar attack on Nixpkgs. The background here is complicated and I don’t fault the project for choosing to operate that way historically. But the risk of compromised credentials and API keys is too high to let the status quo remain in place.
Reducing the risk with cooldowns
To mitigate the risk, we have changed how we ship nixpkgs-weeklynix shell and nix run.
Starting today, nixpkgs-weekly still only updates once a week, but it deliberately introduces a seven-day “cooldown” period, updating to a new revision of Nixpkgs released by upstream only after seven days have elapsed.
This introduces a buffer period where major vulnerabilities or attacks can be identified prior to it arriving in our users’ hands.
Cooldowns are a new and remarkably effective technique for avoiding supply chain attacks. As we learned from cooldowns.dev, a recent analysis of roughly ten of the most prominent supply chain attacks from the past 18 months found that an attacker’s real window of opportunity is almost always measured in hours or days, not weeks; eight of the ten were shut down in under a week. Our cooldown pumps the brakes on the attacker by refusing to adopt any release until it has been public for a week, providing crucial time for problems to be identified first.
This behavior is already deployed and all Determinate Nix users use it by default.
Additionally, flakes that use the bare nixpkgs flake registry entry will use this cooled down Nixpkgs automatically.
If you’re not using Determinate Nix, you can use it too:
{ inputs.nixpkgs.url = "https://flakehub.com/f/DeterminateSystems/nixpkgs-weekly/0.1";}We have started mirroring NixOS 26.05 as well:
{ inputs.nixpkgs.url = "https://flakehub.com/f/DeterminateSystems/nixpkgs-26.05-chilled/0.1";}The way forward
With the currently brewing supply chain crisis, I hope the NixOS project changes this policy and moves to require peer review, despite the obvious negative impact on merge throughput, at least in the short term. This will mitigate one of the largest current security gaps in the project.
I am glad that we can take a meaningful step to securing the greater Nix ecosystem for everybody, for free.
Internally, we are moving all of our inputs to use either Determinate Secure Packages or nixpkgs-weekly.
For enterprise users who want this style of cooldown plus enterprise-grade security, compliance controls, and managed vulnerability remediation, make sure to check out Determinate Secure Packages.
