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

81–90 of 192 posts

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

#81

Post by sirspamalot110 »

dwheeler wrote: post #60
massysett wrote: post #41

Article says that distributions should get source code directly from the VCS (for instance Github) rather than the traditional installation tarball. I don’t see what this solves though. Couldn’t a malicious maintainer simply add binary blobs directly to the source code repository? The author suggests Github is trusted, as though Github validates code in some way. Which of course it does not.

What this solves is the problem that often "what is reviewed" is different from "the source code used to build the software". Verified reproducible builds could have countered the xz utils break, SolarWinds Orion subversion, and many others. It's worth doing.

[dead]

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

#82

Post by sirspamalot110 »

mcint wrote: post #16

Excellent descriptive analysis. Wrong, misleading title, perhaps "technically correct," but at best with a "backdoored" meaning. It points out the need and use for build-manager tools that go a step beyond union file system layers, but track then enforce that e.g. tests cannot pollute build artifacts. Take a causal trace graph of files affecting files, in the build process, make that trace graph explicit, and then bu…

[dead]

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

#84

Post by sirspamalot111 »

vlovich123 wrote: post #4
ltbarcly3 wrote: post #3

Yes, if you use a trusted framework then you are safe from things until that framework is attacked. The xz backdoor might have been detected, but the xz backdoor wasn't crafted with the goal of working against the Nix ecosystem. When a nix core developer ends up being a spy or whatever then there will end up being an attack against the nix ecosystem. Don't reply to this with some claim that Nix is inherently secure u…

The standard never has been and never will be absolute security. That’s an impossible threshold nothing would ever meet even though it’s objectively true that software today is generally more secure than software 30 years ago. The strongman claim being made is “Nix is harder and more expensive to exploit than traditional build systems”. So sure, if you find a cheap way to exploit Nix, track me down. But until then, i…

[flagged]

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

#85

Post by sirspamalot111 »

immibis wrote: post #29
Dwedit wrote: post #19

Earlier quoted context omitted.

Yeah, without the latency regression, it probably would have gone undetected much longer. Using a secondary thread and spreading the CPU load over a few seconds would have made it not even register as a spike in CPU usage.

Or do cheap ECDSA instead of expensive RSA. Even if the backdoor is hidden inside RSA decryption and the rest of the system thinks the thing being decrypted should be encrypted with RSA, you don't have to use it for the back door.

[flagged]

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

#86

Post by sirspamalot111 »

donnachangstein wrote: post #33

NixOS is really irrelevant here because the xz backdoor specifically targeted RedHat and Debian. It's equally relevant to say the xz backdoor didn't affect Windows (ironically the backdoor was ultimately found by a Microsoft employee, an oft-overlooked detail).

[flagged]

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

#87

Post by sirspamalot111 »

nialv7 wrote: post #18

I feel the author is a bit tunnel visioned by what happens to happen this time. The Jiatan incident has a sample size of one, it'd be a bit short sighted to think that's the only way it could happen. You can imagine various scenarios where the defenses suggested here will not have worked. Also I (as a nix user myself) think it's unlikely NixOS would have caught it. As evidenced by the fact that it didn't. (Yeah I rea…

[flagged]

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

#88

Post by easton »

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

I’ll note that macOS doesn’t necessarily always let you do this the first time, it’ll pop a dialogue saying “hey, you’re cool with this app seeing (your files/other apps files), right?” I wonder if such a thing could be implemented in flatpak.
Post reply on HN