Hi @cafkafk,
I thought it might be useful for me to clarify the timeline of this security incident. Especially since this has come up and evolved into other bizarre claims in this thread and across the internet/mastodon/etc. My hope is that it may demonstrate that it was neither an oopsie or impropriety.
The timeline is as follows:
- 3:12P New York – the pull request fixing the vulnerability is published. This included a changelog entry and test case: builtin:fetchurl: Enable TLS verification by edolstra · Pull Request #11585 · NixOS/nix · GitHub
- 5:52P New York – that PR merges into master.
- 5:55P New York – the pull request backporting the fix to 2.24 is opened. builtin:fetchurl: Enable TLS verification (backport #11585) by mergify[bot] · Pull Request #11592 · NixOS/nix · GitHub
- 7:04P New York – the pull request merges builtin:fetchurl: Enable TLS verification (backport #11585) by mergify[bot] · Pull Request #11592 · NixOS/nix · GitHub
- 9:24P New York – Nix 2.24.8 is tagged. Release 2.24.8 · NixOS/nix · GitHub
- 9:32P New York – I start the process of updating Determinate Nix Installer Release v0.26.3 by grahamc · Pull Request #1200 · DeterminateSystems/nix-installer · GitHub
- 10:35P New York – Determinate Nix Installer v0.26.3 is released Release v0.26.3 · DeterminateSystems/nix-installer · GitHub
- 11:32P New York – We complete an expedited rollout phase of Determinate Nix Installer, and we distribute advisory information to our users: x.com
In summary, our communication to our users was over eight hours after the full details of the vulnerability was made public, and over two hours after the upstream Nix release was completed. As far as I can tell, the contents of our advisories did not include any information that wasn’t otherwise completely public.
Why didn’t the Nix team publish the advisory right away? They said weren’t done with it yet: Nix 2.24.8 released fixing builtin:fetchurl credentials leak, severity 5.9 (moderate) - #6 by fricklerhandwerk. I wish it had been, but I also don’t blame them for it. We would be glad to help support the Nix team on this, if that is wanted.
How were we able to act so quickly? We have internal policies and procedures that describes how we handle security incidents. Our procedure documentation includes specific instructions on monitoring for vulnerabilities, our expedited release process, and how and when we communicate to our users. As you have seen, the communication steps include issuing advisories through our general communication channels.
In other words, this is by no means an oopsie, accident, or leak. It is also not part of an effort to delegitimize the Nix project that we are so attached to. It is careful following of procedures.
It isn’t our responsibility to choose to withhold totally public information from our users, especially regarding security issues. Attackers and malicious actors don’t, and communicating actionable information promptly to our customers is part of our responsibility to those customers.
Hopefully this is less scary than it seemed at first blush.