The main issue is the handling of security updates within the Nixpkgs ecosystem, which relies on Nix’s CI system, Hydra, to test and build packages. Due to the extensive number of packages in the Nixpkgs repository, the process can be slow, causing delays in the release of updates. As an example, the updated xz 5.4.6 package took nearly 5 days to become available in the unstable branch!

Fundamentally, there needs to be a change in how security fixes are handled in Hydra. As stated in the article, Nix was lucky to be unaffected, but multiple days to push out a security patch of this severity is concerning, even if there was no reason for concern.

  •  0xtero   ( @0xtero@beehaw.org ) 
    link
    fedilink
    31
    edit-2
    8 months ago

    Kinda tired of the constant flow of endless “analysis” of xz at this point.
    There’s no real good solution to “upstream gets owned by evil nation state maintainer” - especially when they run it in multi-year op.

    It simply doesn’t matter what downstream does if the upstream build systems get owned without anyone noticing. We’re fucked.

    Debian’s build chroots were running Sid - so they stopped it all. They analyzed and there was some work done with reproducible builds (which is a good idea for distro maintainers). Pushing out security updates when you don’t trust your build system is silly. Yeah, fast security updates are nice, but it took multiple days to reverse the exploit, this wasn’t easy.

    Bottom line, don’t run bleeding edge distros in prod.

    We got very lucky with xz. We might not be as lucky with the next one (or the ones in the past).