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

141–150 of 192 posts

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

#141

Post by [deleted] »

jjmarr wrote: post #7
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…

I still like the blogpost, because NixOS bills itself as a technical solution to prevent build artifacts that are decoupled from the source code (i.e. not reproducible), and the xz backdoor was hidden in build artifacts.

[deleted]

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

#142

Post by drpossum »

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…

[flagged]

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

#143

Post by mongol »

dataflow wrote: post #110
donnachangstein wrote: post #108

Earlier quoted context omitted.

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

Because its dependencies are distributed in a compressed tarball.

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

#144

Post by dsp_person »

thdhhghgbhy wrote: post #139

If Jia Tan's PR was approved, malicious artifacts could go to github releases just as easily as in a tarball. Struggling to understand the point made about github releases being a security mitigation.

When I did my first github "release" I was shocked that it involved picking files to upload...

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

#145

Post by mikrotikker »

dsp_person wrote: post #144
thdhhghgbhy wrote: post #139

If Jia Tan's PR was approved, malicious artifacts could go to github releases just as easily as in a tarball. Struggling to understand the point made about github releases being a security mitigation.

When I did my first github "release" I was shocked that it involved picking files to upload...

And how many of these files have I downloaded over the years? :sob:

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

#148

Post by chungy »

__MatrixMan__ wrote: post #136
XorNot wrote: post #133

Earlier quoted context omitted.

Except that's a Windows thing where you don't have boot flexibility. Ubuntu on ZFS can do this as well.

My point is that the lack of boot flexibility caused a lot of problems. If we want to be able to rely on people to get the job done even on days when something is wonky in the bits, then we should give them boot flexibility. NixOS just happens to do it especially well. As for ZFS... Dealing in filesystem snapshots is comparatively a bit awkward. If you want to recreate that config elsewhere you have to move the whole…

> As for ZFS... Dealing in filesystem snapshots is comparatively a bit awkward. If you want to recreate that config elsewhere you have to move the whole snapshot rather than just the recipe for building it

That wasn't the highlight of the point. It was that you can restore to a known good version of the operating system, effortlessly, regardless of what the operating system is. It could be Ubuntu, Nix, or FreeBSD. Broken OS, select an older snapshot in the boot loader, and you're golden again.

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

#149

Post by jstanley »

nextos wrote: post #13
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…

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

> including no access to ~/

This is such a headache with snap and flatpak though.

If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges".

Some examples of sandboxing issues:

* FreeCAD doesn't have access to /usr which means when you try to make a Draft ShapeString you can't pick any fonts

* FreeCAD stores the path to the shape of a milling cutter inside your project, but that path is inside /mnt/.FreeCAhjhffg or whatever so it doesn't work after you restart the program

* Inkscape gcodetools has its own "idiomatic" way of saving out results which doesn't use a file dialog, and therefore can't save any gcode because it can't write to your home directory

* Matrix is only allowed to access ~/Downloads/ which means you can't share any files with anyone unless you copy them into Downloads first

* "Recent" in the Gimp file picker doesn't show any of my recent files, presumably because it is using its own sandboxed file dialog which doesn't have access to the actual "Recent" files

* Docker can't access /tmp/.X11-unix which means you can't give docker containers access to X

In all of these cases you can work around it of course (mainly by having an accurate mental model of the problem and guessing a path that the program is allowed to access), but the user experience is just made worse for no benefit.

The general theme is that the user wants the sandboxed program to be able to do something that the person who assigned privileges didn't think of.

So maybe if we must do sandboxing, let's make it easy for users to break programs out of the sandbox when it suits them?

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

#150

Post by attila-lendvai »

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

a slightly improved version of NixOS (or Guix) would have automatically caught this backdoor once it reached their repos.

they are relevant.

Post reply on HN