That is true.

Binary artifacts have no business existing in Free Software (or near-binary considering how auditable pre-generated config scripts end-up being). The way it was compromised in this case is almost certain to have happened before and reminds me of the SourceForge malware debacle (so arguably that's another famous example of it happening before).

I"m not sure if many other projects do like Guix and record the checksum of the whole repository so as to ensure reproducibility purely from source.

In this case the actual malicious vector was the near-binary injected code in the practical binary of the unaudited autotools vomit (always autoreconf) which was then bundled in the actual binary artifact that was the compromised tarballs.

None should have ever been part of the project.

As for the test files, I still think that having a hex dump with comments explaining what flaws particular parts test would be desirable in a lot of cases.

@lispi314 @glyph The actual backdoor code was part of binary test vectors for the LZMA algorithm (and is an actual amd64 binary object file). Autotools goop was just how it was triggered/injected into the build system.

In this case the build system side was rather noisy, but you could make it a lot more subtle. Something like a subtly incorrect glob could be engineered to "accidentally" match a test data file that then gets linked into the build process in some way.

Right, I suppose I did omit to mention that one.

Though that suggests my initial statement of "no binaries, full stop" is the right idea.

It's my understanding that at that point though, you're trusting the developers of the CPU assembly/byte/machine code.

The problem isn't necessarily the binaries - it may have been harder to do so, but they could've hid it in a commonly distributed compiler ala ( cs.cmu.edu/~rdriley/487/papers… ) - it's a matter of trust in the person doing the development.

Part of the problem is that the developer's submissions were pushed with less review than necessary.

Indeed, unfortunately until we have Libre FPGAs and the ability to verify their design and configuration, it is necessary to trust the hardware.

In my post here: udongein.xyz/notice/AgMU728f3a…

One of the articles (I'm not sure which again) explicitly links to the Trusting Trust problem & documentation.

It is possible, if tedious, to bootstrap a Forth implementation in a minimal amount of machine code in an hex editor or other basic input method, and then retain the ability to audit both the initial binary bootstrap seed and then bootstrap everything else from source.

Of course in this case the Guix project contributors decided that a small Scheme (which iirc isn't standard-compliant) interpreter would do.

The commits weren't adequately reviewed, yes.

That said, if binary artifacts like tarballs weren't accepted, and pratically binary by its difficulty of auditing autotools vomit was deemed equally unacceptable (better use autoreconf on whatever dev machine is used to build the project as necessary), it would be far more difficult to replicate this incident.

LisPi

2024-03-30 01:12:05

GCC as well.

Ref:
- guix.gnu.org/blog/2019/guix-re…
- guix.gnu.org/blog/2020/guix-fu…
- guix.gnu.org/en/blog/2023/the-…

Guix Reduces Bootstrap Seed by 50% — 2019 — Blog — GNU Guix

Blog posts about GNU Guix.

^guix.gnu.org

@lispi314 @glyph @AT1ST You should look up Precursor:

bunniestudios.com/blog/?p=5921

TL;DR there is a very legitimate argument that backdooring an FPGA generically is impractical, so libre FPGA configuration (and ideally libre FPGA toolchains) plus inspectable hardware generally suffice for a high level of trust.

However, this will never be practical for high performance general purpose compute, only for very limited applications like this. I don't think anyone has any good ideas on how to solve the trustability problem for things like desktop PC or smartphone class hardware. It might never be possible.

@dgilman
From the same thread:

"Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project.

> If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released."