[flagged]
NixOS and reproducible builds could have detected the xz backdoor
61–70 of 192 posts
Re: NixOS and reproducible builds could have detected the xz backdoor
#62Note 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…
[dead]
Re: NixOS and reproducible builds could have detected the xz backdoor
#63Earlier 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…
>My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. Besides how large the package repos are, what other reasons would one chose Guix over NixOS?
Non-standard services daemon vs systemd.
Otherwise, available packages are tidy and well defined.
NixPkgs, which I use and develop for, is less tidy.
Re: NixOS and reproducible builds could have detected the xz backdoor
#64[dead]
Re: NixOS and reproducible builds could have detected the xz backdoor
#65Note 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…
[dead]
Re: NixOS and reproducible builds could have detected the xz backdoor
#66NixOS 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).
[dead]
Re: NixOS and reproducible builds could have detected the xz backdoor
#67llm commit scanning might be an interesting approach to the oss supply chain security problem.
[dead]
Re: NixOS and reproducible builds could have detected the xz backdoor
#68Earlier quoted context omitted.
The article does in fact cite the reproducible-builds project, in the section on "Leveraging bitwise reproducibility". From your comment I am not convinced you understood the point of the article, which is: * the NixOS build process was unable to perform a full-source build of xz because xz is required too early in the bootstrap; * a proposed adjustment to nixpkgs to automatically detect compromises of nixpkgs depend…
I see.
[flagged]
Re: NixOS and reproducible builds could have detected the xz backdoor
#69I 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
#70Article 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.
[flagged]