Earlier quoted context omitted.
Why call it "Cppnix"?
Because it's written in C++ and the fork plans to rewrite in Rust?
> fork plans to rewrite in Rust
Lmao. Won't ever happen.
Nix 2.24 is vulnerable to (remote) privilege escalation
41–50 of 81 posts
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#42I don't get why someone who responded to this calls this something other than responsible disclosure. puck clearly writes, "at this point the disclosure timeline has passed". It's on Nix to meet the disclosure timeline. Missing that is Nix being irresponsible, not puck. I see this often, and it's not a good look when people would rather punish the reporter of an issue rather than the organization that was given plent…
> the organization that was given plenty of time One week doesn't seem like "plenty of time" to me. The guy who ack'd the initial report and created the vulnerability tracker in GitHub was on vacation.
More context:
> The vulnerability report doesn’t mention it directly, but the discussion thread about it on Fedi gives some more context on that deadline: the reporter has had several previous vulnerability reports completely ignored by the Nix development team, including one open since February and still untriaged. The Nix development team received and acknowledged this new Nix 2.24 vulnerability on August 30th (so, > 9 days ago) and they seem to have mostly sat on it until today (the reporter received no further comms), to the extent that a new point release of Nix was released a few days after the vuln was reported and did not contain a fix.
Source: https://lobste.rs/s/ixb3v7/nix_2_24_is_vulnerable_remote_pri...
The first one from Feb: https://matrix-client.matrix.org/_matrix/media/v3/download/p...
It's a community project run by volunteers but I don't think such response ("Impact: blabla") to a vulnerability gives a good impression to your users.
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#43This is fixed in 2.24.6: https://github.com/NixOS/nix/releases/tag/2.24.6 See also https://discourse.nixos.org/t/vulnerability-in-nix-2-24/5190... for updates. Can someone link to the actual fix? It's a bit hard to navigate the git history for me...
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#44Earlier quoted context omitted.
Also there's too many things called Nix. There's the overall project, the language, and the primary interpretation. It's also why you'll sometimes see nixlang to refer to the language.
Thought was the norm using capitalized for language and lower case for the tooling. So Nix/nix, like AWK/awk and Go/go.
Full caps AWK feels like a relic from the screaming UNIX days, and golang for Go is incredibly common (and as far as I can tell, the proximate cause of the nixlang term)
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#45technicals aside, as they are now resolved or being resolved in one manner or another, i would really like an understanding of precisely where the breakdown in communication occurred. i have thus far heard conflicting reports that indicate either the relevant nix org team dropped the ball, or was doing things right and got the rug pulled out from under them, which indicate respectively that puck was either exercising…
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#46This is fixed in 2.24.6: https://github.com/NixOS/nix/releases/tag/2.24.6 See also https://discourse.nixos.org/t/vulnerability-in-nix-2-24/5190... for updates. Can someone link to the actual fix? It's a bit hard to navigate the git history for me...
I think it is https://github.com/NixOS/nix/commit/12fa019ae558641df0a23a79...
How can such a simple code change fixes such a big vulnerability?
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#47Earlier quoted context omitted.
Someone who writes a response to a security vulnerability report, includes nobody else in the discussion, then leaves for vacation within 15 minutes of sending that report is irresponsible. Giving someone a week to respond is not unreasonable. If nobody responds in a week, it can safely be assumed that they don't take security seriously, and the responsible thing is to let the community know. Spin it how you like, bu…
This is a very poor take. The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously. You may not be aware, but since a group of maintainers and contributors left earlier this year to form their own fork called "Lix," there have been many vacant positions across several Nix teams. They actually held a meeting about the security issue earlier in the day before the di…
> The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously. You may not be aware, but since a group of maintainers and contributors left earlier this year to form their own fork called "Lix," there have been many vacant positions across several Nix teams.
> The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously. You may not be aware, but since a group of maintainers and contributors left earlier this year to form their own fork called "Lix," there have been many vacant positions across several Nix teams
Normally I'm sympathetic to claims about people being entitled to work from open source projects, but in this instance, I don't think this is the case. If this were a request for a feature or a bug without significant security impact, expecting any sort of timeline at all would be unreasonable, but I don't see how not having enough people to work on a project would imply that users should be left vulnerable for longer. In my opinion, it's much more "entitled" to demand that a known security bug in your own code base be hidden from your users because you would prefer to keep working on whatever you're currently doing.
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#48Earlier quoted context omitted.
Someone who writes a response to a security vulnerability report, includes nobody else in the discussion, then leaves for vacation within 15 minutes of sending that report is irresponsible. Giving someone a week to respond is not unreasonable. If nobody responds in a week, it can safely be assumed that they don't take security seriously, and the responsible thing is to let the community know. Spin it how you like, bu…
that's a bit entitled. I'm coming over for dinner, I hope you're prepared.
This isn't "I'm entitled to free dinner", this is "your dinner guests are getting sick from food poisoning, and you're demanding I don't tell them".
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#49Earlier quoted context omitted.
Someone who writes a response to a security vulnerability report, includes nobody else in the discussion, then leaves for vacation within 15 minutes of sending that report is irresponsible. Giving someone a week to respond is not unreasonable. If nobody responds in a week, it can safely be assumed that they don't take security seriously, and the responsible thing is to let the community know. Spin it how you like, bu…
This is a very poor take. The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously. You may not be aware, but since a group of maintainers and contributors left earlier this year to form their own fork called "Lix," there have been many vacant positions across several Nix teams. They actually held a meeting about the security issue earlier in the day before the di…
> The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously.
If the nix volunteers aren't held to reasonable security defect reporting standards, why do you hold the vulnerability reporter to higher standards? I'd say, if the rule is volunteers are able to YOLO with other users' security so can the reporters right?
Re: Nix 2.24 is vulnerable to (remote) privilege escalation
#50Earlier quoted context omitted.
> before the disclosure and had reached out to the reporter(0). First, the only link you provided doesn't look to be related to this issue. Edit: I see it bizarrely redirects to " https://discourse.nixos.org/t/iohk-hiring-devops-with-nix-ex... ". What happened to the minutes? Second, I understand that it's run by volunteers, that they might not have the humanpower they need, and so on - as a volunteer who spends a go…
Can't tell what happened to the earlier link but I've fixed the it. Puck was being malicious in releasing the information . There's no favourable way of describing disclosing a vulnerability on social media because the maintainers didn't meet your 7 day deadline. It's more of "we're forcing their hands since they haven't met our expectations yet" thing. There's so many ways they could've gotten a timely fix without "…
> Puck was being malicious in releasing the information.
[citation needed]
> There's no favourable way of describing disclosing a vulnerability on social media because the maintainers didn't meet your 7 day deadline.
personally I'm grateful he didn't sit on a remote privexc vulnerability for 90days when he was confident it wasn't going to be fixed. I think you're conflating public disclosure (security though obscurity) with real harm, compromise due to the bug. If Puck found it, others who would gladly sell it for coin on the black market, would have found it.