3 ms·

So the argument hinges on the fact that the XZ maintainer hid malicious code in the tarballs that were not checked into Git. The author demonstrates that Nix c

So the argument hinges on the fact that the XZ maintainer hid malicious code in the tarballs that were not checked into Git. The author demonstrates that Nix can be configured to generate the tarballs from git that go into building the binaries. What I don't see, however, is how is this a feature that requires Nix or NixOS? Any build system out there (including the stuff that goes into RPMs and Debs) can be configured to generate tarballs as a intermediate step. In fact making reproducible builds is a major thing that Debian has been working on for some time now. https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds

Smaug123 2y ago
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 dependencies which are required early in the bootstrap. Other ecosystems can of course also attempt full-source builds and discover the discrepancy; the entire point of the article is that nixpkgs currently cannot.
- lotharcable 2y ago
  I see.
  - sirspamalot103 2y ago
    [dead]
  - sirspamalot106 2y ago
    [flagged]
- sirspamalot112 2y ago
  [dead]
sirspamalot103 2y ago
[dead]
sirspamalot108 2y ago
[flagged]