CVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
General PSA that if you are scanning your system for potentially malicious binaries, running ldd on them is not something you should do. Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
Guix has grafts precisely for this purpose. Can’t we have something similar? What roadblock as would there be for implementing and then utilizing such change? Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
dpc: It should be possible to opt-in into some very-early-unstable-head-channel, that guarantees only a core subset built (toolchains and core utilities, possibly only for x86_64 That actually does...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
We shouldn’t wait for the rebuild, xz, libarchive, all related packages should be removed/marked insecure and pushed to master. Let people rebuild what they need themselves. There is reason to believe...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
Yeah, you can also check it by enabling the backdoor condition against a problematic binary: $ nix build -f '<nixpkgs>' xz.out --out-link before $ nix build --impure --expr 'with import...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
L-as: We shouldn’t wait for the rebuild, xz, libarchive, all related packages should be removed/marked insecure and pushed to master. Why do you think that we should remove or mark as insecure all...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
L-as: Let people rebuild what they need themselves. It is not as simple as that. As already mentioned before, xz is part of the bootstrap binaries through that stdenv which means you cannot even write...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
(Point of order: could the “what kinds of source distribution should nixpkgs accept” discussion please go to a new thread? It’s unrelated to the current remediation efforts.) Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
14k store paths, why does everything depend on xz anyway? How long would it there to build it for you? Is it not worth not having the vulnerabilities? Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
12 posts were split to a new topic: Reconsider reusing upstream tarballs Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
10 days is a very long time for such a critical security update, and we need to be better for the next time this happens. Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
xz is part of stdenv (along with a few other tools). It’s needed to unpack .tar.xz tarballs. Virtually everything depends on stdenv. nix why-depends might help you figure they details: $ nix...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
L-as: How long would it there to build it for you? Is it not worth not having the vulnerabilities? I would estimate it to be at least a couple of days if not a week and I would need to baby sit it and...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
trofi: xz is part of stdenv (along with a few other tools). It’s needed to unpack .tar.xz tarballs. Virtually everything depends on stdenv. It seems that the main problem here is not that xz (the...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
I’m not sure I understand. xz does link against (it’s own) liblzma: $ lddtree `which xz` /run/current-system/sw/bin/xz (interpreter =>...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
trofi: If we are to fix liblzma we should relink xz as well. Yes. My point is that we don’t need to update the xz binary that is used in stdenv (or at least not right away), if we ensure that it’s...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
Unless you have a more systemic fix you’re thinking of, this is really just over fitting a fringe/one-off event. Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
The maximal version of what I am proposing is a systemic fix. Basically, split all the dependencies of stdenv into two groups “build tools” and “libraries provided by default”. Enforce that the first...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
Aside from the complexity of the implementation how much do you expect to gain from such a change? What the rebuild decrease would you call a net benefit for that? 2x? 10x? 100x rebuild speedup? Let’s...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
payas: Guix has grafts precisely for this purpose. Can’t we have something similar? What roadblock as would there be for implementing and then utilizing such change? I’m also wondering about this. I...
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
FYI, the downgrade of xz is in nixpkgs master now. *-linux binaries are basically all there. Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
hey, that didn’t take too long at all! Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
heads up that the PR reverting xz is now in nixos-unstable and nixpkgs-unstable https://nixpk.gs/pr-tracker.html?pr=300028 Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
This prompted us to add support for content addressable store to Cachix and see how much it would help with saving the rebuilds. I’ll report back once we have some results. Read full topic
View ArticleCVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs
@domenkozar Do you have any results by now? Read full topic
View Article