[dead]
NixOS and reproducible builds could have detected the xz backdoor
121–130 of 192 posts
Re: NixOS and reproducible builds could have detected the xz backdoor
#122Is the massive number of spam messages on this thread an attempt to suppress the article / discussion around it? I've not seen this many from multiple but evidently related green accounts before. Given the implications about nation state actors in play, it's tempting to jump to conclusions here.
No, this has been happening for a few days now. Browse threads from the past week with showdead enabled and you'll see them.
> showdead enabled
Thanks, I didn't know this was something we could turn off. Although it does feel like they could just default to collapsed too.
Re: NixOS and reproducible builds could have detected the xz backdoor
#123Is the massive number of spam messages on this thread an attempt to suppress the article / discussion around it? I've not seen this many from multiple but evidently related green accounts before. Given the implications about nation state actors in play, it's tempting to jump to conclusions here.
It's multiple threads, not just this one, and it's been on and off the past few days. You can add these kind of lines: news.ycombinator.com##tr.athing.comtr:has(a.hnuser:has-text('banana_dick')) news.ycombinator.com##tr.athing.comtr:has(a.hnuser:has-text('sirspamalot')) to any uBlock or AdBlockPlus type extensions with manual compatible custom filters that you might have added to your browser. > It's quite amazing th…
[dead]
Re: NixOS and reproducible builds could have detected the xz backdoor
#124Earlier quoted context omitted.
> This would make it convenient to run every single process with restricted privileges, including no access to ~/ Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error.…
>You can often only drag 'n drop from ~/Downloads/ Drag and drop could be made to always work since it's being done by a user. Request this feature from your operating system's developer.
Then I have to ask for printing to always work. Then something else that I haven't even thought of yet. Security is hard because there are so many details that must be right or you compromise useability/usefulness.
Re: NixOS and reproducible builds could have detected the xz backdoor
#125Earlier quoted context omitted.
> This would make it convenient to run every single process with restricted privileges, including no access to ~/ Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error.…
>You can often only drag 'n drop from ~/Downloads/ Drag and drop could be made to always work since it's being done by a user. Request this feature from your operating system's developer.
Is it? There is such a thung as GUI automation. It's not a very popular exploit vector because it is visible, and because there are simpler non-GUI exploit vectors available. But nothing fundamentally stops an attacker process from pretending it's accessibility software and taking control of the mouse to do a drag-n-drop.
Re: NixOS and reproducible builds could have detected the xz backdoor
#126Is the massive number of spam messages on this thread an attempt to suppress the article / discussion around it? I've not seen this many from multiple but evidently related green accounts before. Given the implications about nation state actors in play, it's tempting to jump to conclusions here.
It's multiple threads, not just this one, and it's been on and off the past few days. You can add these kind of lines: news.ycombinator.com##tr.athing.comtr:has(a.hnuser:has-text('banana_dick')) news.ycombinator.com##tr.athing.comtr:has(a.hnuser:has-text('sirspamalot')) to any uBlock or AdBlockPlus type extensions with manual compatible custom filters that you might have added to your browser. > It's quite amazing th…
Still leaves me curious about the "why". Someone mad at HN about something? Just having a laugh?
Re: NixOS and reproducible builds could have detected the xz backdoor
#127Earlier quoted context omitted.
>You can often only drag 'n drop from ~/Downloads/ Drag and drop could be made to always work since it's being done by a user. Request this feature from your operating system's developer.
Is it? There is such a thung as GUI automation. It's not a very popular exploit vector because it is visible, and because there are simpler non-GUI exploit vectors available. But nothing fundamentally stops an attacker process from pretending it's accessibility software and taking control of the mouse to do a drag-n-drop.
GUI automation is typically locked down heavily and would not be something you would give to random applications.
Re: NixOS and reproducible builds could have detected the xz backdoor
#128Note that NixOS and reproducible builds did not detect the xz backdoor, and in fact NixOS shipped the malicious builds of xz (though they didn't do anything because the malware didn't target NixOS): > I am a NixOS developer and I was surprised when the backdoor was revealed to see that the malicious version of xz had ended up being distributed to our users. As always theory and reality are different, and the thing th…
> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…
I get the potential need for such draconian measures in perhaps, some top secret government installations or something, but gosh that sounds tiring -- a lot like MacOS lately asking me "(AppName) wants to access your Downloads folder, cancel or allow?" when I have just directed it to open a file.
Re: NixOS and reproducible builds could have detected the xz backdoor
#129Why is nobody questioning this: > To build xz from sources, we need autoconf to generate the configure script. But autoconf has a dependency on xz! Both directions of this seem crazy to me. 1. Why the heck should a build configuration tool like autoconf be unable to function without a compression tool like xz? That makes no sense on its face. 2. For that matter, why the heck should xz, a tool that is supposedly so fu…
[flagged]
If you know of a reason for autoconf and xz to be hard dependencies of one another, you can just say it.
Re: NixOS and reproducible builds could have detected the xz backdoor
#130llm commit scanning might be an interesting approach to the oss supply chain security problem.
Commit scanning probably wouldn't have caught this, since the backdoor happened outside of any commit.
Comparing the tarball's contents against the VCS repository would've likely made this easier to catch, but at that point you might as well just use the VCS repository directly.