Hacker News Reader

Comment by ltbarcly3 | Hacker News Reader

Yes, if you use a trusted framework then you are safe from things until that framework is attacked. The xz backdoor might have been detected, but the xz backdoor wasn't crafted with the goal of working against the Nix ecosystem. When a nix core developer ends up being a spy or whatever then there will end up being an attack against the nix ecosystem. Don't reply to this with some claim that Nix is inherently secure unless you want me to track you down and make you admit you were wrong when Nix ends up getting successfully exploited in a year or two.

View on HN

The standard never has been and never will be absolute security. That’s an impossible threshold nothing would ever meet even though it’s objectively true that software today is generally more secure than software 30 years ago. The strongman claim being made is “Nix is harder and more expensive to exploit than traditional build systems”. So sure, if you find a cheap way to exploit Nix, track me down. But until then, it remains at least plausible & in practice very likely that Nix is harder to exploit than alternate systems on a technical level.

> But until then, it remains at least plausible & in practice very likely that Nix is harder to exploit than alternate systems on a technical level.

Do people even read package derivations? Feels like it'd be easy to check in a derivation with an exploit.

The backdoor was not targeting Nix but it had to not raise any suspicion during a build in Nix to not be exposed.

The backdoor build script specifically checked for things indicating that it's being built for debian, and if not, not inserting the backdoor; so it only ever was non-reproducible in situations where reproducibility wasn't expected. Not hard to make sure a backdoor with control over the build environment doesn't raise suspicions in non-targeted places.

also wasn't the backdoor reproducible to begin with? If it had targeted every system, you'd just get reproducible backdoored binaries.

The infected version was only the tarball, which was part of the obfuscation (i.e. people may look at git commits, but who individually checks autogenerated code in tarballs of every release)

Building from the git commit the release claimed to be from would result in a different binary than building from the tarball if the environment check passed.

Reply on news.ycombinator.com