This is an astounding amount of word-twisting for someone who was just offered an opportunity to collaborate on these types of issues with someone else in the space who’s directly working on them.
We are here, first and foremost, as individuals working together. Our priority here is to work on Nix projects for the benefit of all their contributors and users.
Also:
And it’s not surprising you’d be so willing to act in such a irresponsible and frankly hobbyist way,
At the end of the day, I am a enterprise user
… to elevate your own mediocre (and mostly non-existing) products.
As a reminder:
We treat each other with respect and civility. No matter one’s individual identity, circumstances, level of contribution to the project, or status, everyone has the right to respect, and everyone has the duty to treat others with respect.
Sure, you can make the argument that individual interests were being prioritized over project interests here, and maybe there is a good argument for that. However, you were also just offered an olive branch and refused it, instead doubling down on the “it was a leak” narrative. This is not a black and white “detsys is exiled or not” problem, and pretending it is would be just as counterproductive as replacing the word “detsys” in the previous with Lix. If we are to get along in all our communities, we can’t just stick our heads in the sand and decide that other people using Nix are personae non gratae. It’s crazy and only breeds resentment.
Thanks - and sorry for not having seen that before. Maybe I’m unduly suspicious of motives and attitudes, and that isn’t being fair. I agree now that the information you shared on Twitter was by that time public, and sharing it wasn’t unreasonable. Clearly it was something else that went wrong in that scenario.
Can you help me understand specifically what was privileged and when I learned about it? Because the timeline I outlined above is I think fairly clear that the information we had and publicized was not privileged at the time.
I would expect them to be in the same scenario I was in, where I found out about the vulnerability when the PR documenting it was made public.
In your summary, you have some fairly incredible claims:
Do you have evidence of this?
Should we have waited until nixpkgs had accepted a patch? When the advisory is published? Or can we agree that the information was public when the PR was submitted, and 2x so when the release was finished?
Again, I would appreciate evidence or specifics about what we knew that we should not have, what was privileged, when we learned about it, when it stopped being privileged, etc.
It isn’t our responsibility to be the liaison between the Nix team and the Nixpkgs team. They’re equally capable as we and anyone else is of clicking “Watch” on the Nix repository and get attention-getting emails subjected “builtin:fetchurl: Enable TLS verification” directly in their inbox.
It should definitely have been until it was in Nixpkgs’s stable and unstable branches. I don’t know how the Nix team came to this (IMO wrong) conclusion, but I assume it isn’t the sole responsibility of the DetSys team.
Why? If curl releases a security patch, is nobody allowed to talk about it until it’s in Nixpkgs stable and unstable branches? Of course not; Nixpkgs isn’t the arbiter of what is and isn’t available to all people. What makes the Nix package different? Many people get Nix through Nixpkgs but there are other ways as well, and DetSys is the steward of one of those other ways. It seems wrong to chastise them for not delaying notifying their users until Nixpkgs catches up, just like it would be wrong to chastise Debian for notifying their users about a fresh fix available in Debian but not in NixOS yet.
Come on, this is a terrible example and not even close to the same.
This is bad because curl is a totally separate piece of software, separate team, separate project. There is no synergy between the nix team and the curl team. Nobody is working on nix and on curl.
For nix we’re talking about overlapping teams on the same piece of software.
To go further, since DetSys has a “playbook” and people paid to work on the project, is this going to happen every time there is a vuln in nix or some analogous application that they share with the community? Based on Graham’s response I’d think “Yes this is exactly how it’ll be” and that doesn’t sit well.
Edit: Also seems to go against DetSys’ values of “providing the best vibes”
I agree with this. If I were part of the nixpkgs security team, or whomever might be concerned about this, and I actually had a problem with the actions of DetSys, I’d reach out and talk to them (or any other company or person). If there was any problem with their actions, I’d see if I could work out a solution with them.
Thank you for sharing a snippet of our values. Some further values are being calm, rational, and expansive when we talk to each other, and people externally, too.
In this case, declining to communicate public information about a patched vulnerability to our customers fails the values of both “support the user” and vibes. I appreciate that as someone who doesn’t use our software, you may not like how these particular vibes sit with you.
An unfortunate truth is that the vulnerability information was public. I could stop there and allow the the conversation to continue, but I’m happy to share a bit more.
–
Earlier, I posed a couple hypotheticals that I’ll now answer.
[Should we have waited until] the advisory [was] published?
No. The information is public, and users deserve to have the best information they can, and the best security posture they can. In a red/blue team setup, defenders need every advantage they can get. Red teams don’t wait for advisories.
Instead of asking us to wait, another approach is exploring with the Nix team how to ensure future disclosures are accompanied by advisories. Like I said above, we’d be glad to participate in supporting that.
Should we have waited until nixpkgs had accepted a patch?
It should definitely have been until it was in Nixpkgs’s stable and unstable branches.
Definitely not. If we had, it would have extended the window of a public-but-unaddressed vulnerability significantly more. In this scenario, it would have required:
Pushing a PR to nixpkgs master
Waiting for evaluation checks to pass
Merging
Opening up backport PRs
Waiting for evaluation checks to pass
Triggering evaluations on the unstable and release branches
Waiting hours-to-days for the evaluation, build, and release process to complete
…all before being able to share with our users information that was visible, plain as day, on the Nix issue tracker. I don’t find this to be a realistic position to take. And actually, I challenge the premise that Nixpkgs / NixOS has a particularly unique synergy, given that Nix itself is its own project with its own users and goals.
It could be argued that to NixOS’ release process could be improved to support sudden/urgent releases, but that again is not our responsibility as a distributor of Nix. This is also technically very challenging, for various reasons that we explored when I was trying to get NixOS on the embargoed distro list.
Instead of asking us to wait, another option could be publishing the advisory with information about how to incorporate the patched Nix into your NixOS configuration immediately. This would let NixOS users use the patched version, and they can optional remove it after the fact.
–
To be clear, and without the spooky quotes: yes, we do have a playbook (a term of art to describe a documented process) on how to handle scenarios like this.
And yes, as I said above – our customers and security auditors expect us to follow that process. If absolutely nothing changes about how the Nix team handles security incidents: That is exactly how it will be. However, given the recent incidents and retrospectives, I am optimistic the team’s process will improve – for which I am grateful for and glad of. I’d be glad to help.
There doesn’t need to be a connection between Nix and curl. I was constructing a parallel example in which curl took the place of Nix, not in which curl took the place of something with a non-trivial connection to Nix.
To reiterate: the claim being made is that DetSys (party A) should not announce that a security fix for the Nix implementation (party B) is available through DetSys’s channels until it has also been made available through Nixpkgs (party C). I question that claim because we would not expect Debian (party A′) to refrain from announcing that a security fix for curl (party B′) is available though Debian’s channels until it has also been made available through Nixpkgs (party C′). If this is a bad comparison, it’s not because of the lack of a relationship between B and B′. It must be because of some feature of the A-B-C triple that is not present in the A′-B′-C′ triple. I can’t tell whether it’s because of something about the A-B relationship (DetSys and the Nix team), something about the B-C relationship (Nix and Nixpkgs), or something about the A-C relationship (DetSys and Nixpkgs), or whether it’s some emergent property of all three.
I have done some investigation and the overlap is pretty small! DetSys lists its people, the Nix team is enumerated here, and Nixpkgs is owned by hundreds (or thousands, depending on how you count) but if you look at the set of people who have committed to the pkgs/tools/package-management/nix tree in the last year with:
you will see that it doesn’t contain any overlap with DetSys.
So what is the overlap that we’re talking about? Is it that members of the Nix team also contribute to Nixpkgs? If so, how is that relevant? If a curl maintainer applied for and received commit bits on Nixpkgs, would you impose the same embargo requirement for already-published security fixes for curl?
Or is it that Eelco is on the Nix team and a founder of DetSys? If so, how is that relevant? If the Nix team and DetSys were literally the same team—if there was one group of people who write and maintain and provide commercial support for a piece of software, and that software is on Nixpkgs, are they obligated not to announce security fixes until the fixes are available on Nixpkgs? And if not, why is it a problem if they have a partial overlap instead of a total overlap?
I’m not a fan of several other choices DetSys has made, but it seems like some of you are holding DetSys to an unusual and (in light of Graham’s post) unrealistic standard in this scenario, and I can’t figure out what the principle is that would lead a reasonable person to justify that standard only in this specific case! I’d appreciate it if you could put that principle into words.
Oh, I see. I think in a practical sense, it would be very hard to create a process where Nix can be released from Nixpkgs before (or coincident with) Nix itself has a public release.
