Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixOS and reproducible builds could have detected the xz backdoor

luj.fr

Post reply on HN
Print view View original

101–110 of 192 posts

Re: NixOS and reproducible builds could have detected the xz backdoor

#101

Post by nextos »

jorvi wrote: post #35
nextos wrote: post #13

Earlier quoted context omitted.

> 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…

> 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.…

Why? I am just asking for a simple UI, which Guix already has. Mainly for CLI applications. The idea is to be able to launch an ephemeral shell with any combination of packages, filesystem R/W privileges, and network access in a convenient way.

I think launching e.g. a Python shell with some packages that are potentially compromised and letting those read ~/.ssh and whatever else they want is fundamentally insecure. Rogue PyPI packages that steal SSH keys is not a theoretical security breach, it already happened several times [1].

The current security model in Unix is untenable. But I agree well-implemented sandboxing should be frictionless. What you are experiencing is probably a X or Wayland sandboxing glitch. I also dislike Flatpak, for other reasons, but that doesn't make sandboxing a bad abstraction. It's just that we don't happen to like this particular implementation.

[1] https://www.packtpub.com/en-tw/learning/tech-news/python-lib...

Re: NixOS and reproducible builds could have detected the xz backdoor

#103

Post by banana_dick_1 »

lolinder wrote: post #5

Note 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…

[flagged]

Re: NixOS and reproducible builds could have detected the xz backdoor

#104

Post by nextos »

XorNot wrote: post #43
nextos wrote: post #25

Earlier quoted context omitted.

> It’s possible to do this entirely in systemd service configuration Sure, but I think that leaves out many use cases. What if I want to e.g. start a Python shell that has access to certain directories, and nothing else, including no network access? Nix provides a good way of doing that for common use cases, as it has decent support for Firejail. But I would like something like Guix containers, which is convenient fo…

Literally any container runtime can do this for you. No one does it though because it's annoying as hell to upfront figure out what you want, and then be unable to increase that list later. Like if I were to try and find a not annoying way to do this, it would be to snapshot and overlay mount my filesystem at process launch time, then give a heuristic warning at process termination about what was changed. But then we…

Firejail and bwrap can do this in a relatively convenient way, but adding nix shell on top of that is quite clumsy.

In a regular distro, it is tolerable, but a better UI would be great.

Re: NixOS and reproducible builds could have detected the xz backdoor

#107

Post by skywhopper »

dataflow wrote: post #100

Why 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]

Re: NixOS and reproducible builds could have detected the xz backdoor

#108

Post by donnachangstein »

dataflow wrote: post #100

Why 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…

> 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.

At face value, both autoconf and its cousin pkg-config are overly complex dogshit software - both with circular dependencies - that should have been retired long ago in favor of something else. I scream with joy when I use software that uses its own bootstrapper or cmake.

Before you think "but I've never had this problem, you must be bonkers" - try building software on a fresh Solaris box with no GNU anything installed and you need to install one of these monstrosities with their circular dependencies. Your hair will fall out before you're done.

Re: NixOS and reproducible builds could have detected the xz backdoor

#109

Post by sollewitt »

immibis wrote: post #26
nextos wrote: post #13

Earlier quoted context omitted.

> 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…

It's interesting to observe that every process is already restricted to only be able to do computation by default. Then along comes the OS with a plethora of holes in the sandbox to do various things. And then it's strange that we take those holes for granted and apply bandaid patches over them instead of not creating the holes to begin with. Why can't we ask the kernel to create a new extremely limited memory map an…

https://fuchsia.dev/fuchsia-src/get-started/learn/intro/sand...

Re: NixOS and reproducible builds could have detected the xz backdoor

#110

Post by dataflow »

donnachangstein wrote: post #108
dataflow wrote: post #100

Why 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…

> 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. At face value, both autoconf and its cousin pkg-config are overly complex dogshit software - both with circular dependencies - that should have been retired long ago in favor of something else. I scream with joy when I use software that uses its own bootstrapper or…

>> 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.

> At face value, both autoconf and its cousin pkg-config are overly complex dogshit software - both with circular dependencies - that should have been retired long ago in favor of something else. I scream with joy when I use software that uses its own bootstrapper or cmake. Before you think "but I've never had this problem, you must be bonkers" - try building software on a fresh Solaris box with no GNU anything installed and you need to install one of these monstrosities with their circular dependencies. Your hair will fall out before you're done.

I've used & seen plenty of the mess of autoconf, thank you. It's a hell I don't want to go back to, and it's a hell a lot of people successfully avoid. But even then, I've also never noticed it requiring compression or decompression, which is partly what boggled my mind at the statement.

In any case, the question was: why should autoconf have a hard dependency on xz? Your response to that was autoconf is complicated and has circular dependencies? How is that a response? That was the premise of the question, not the answer.

Post reply on HN