←back to thread

Fifty Years of Open Source Software Supply Chain Security

(queue.acm.org)
182 points yarapavan | 1 comments | 07 Apr 25 18:04 UTC | HN request time: 0s | source
Show context
neuroelectron ◴[07 Apr 25 21:30 UTC] No.43616167[source]▶
Very suspicious article. Sounds like the "nothing to see here folks, move along" school of security.

Reproducibility is more like a security smell; a symptom you’re doing things right. Determinism is the correct target and subtly different.

The focus on supply chain is a distraction, a variant of The “trusting trust” attack Ken Thompson described in 1984 is still among the most elegant and devastating. Infected development toolchains can spread horizontally to “secure” builds.

Just because it’s open doesn’t mean anyone’s been watching closely. "50 years of security"? Important pillars of OSS have been touched by thousands of contributors with varying levels of oversight. Many commits predate strong code-signing or provenance tracking. If a compiler was compromised at any point, everything it compiled—including future versions of itself—could carry that compromise forward invisibly. This includes even "cleanroom" rebuilds.

replies(4): >>43616257 #>>43617725 #>>43621870 #>>43622202 #
lrvick ◴[07 Apr 25 21:41 UTC] No.43616257[source]▶
The best defense we have against the Trusting Trust attack is full source bootstrapping, now done by two distros: Guix and Stagex.
replies(2): >>43616330 #>>43625793 #
egberts1 ◴[08 Apr 25 19:52 UTC] No.43625793[source]▶
Gentoo is a full source boostrapping if you include the build of GRUB2 and create the initramd file as well as the kernel.
replies(1): >>43626690 #
lrvick ◴[08 Apr 25 21:34 UTC] No.43626690[source]▶
Full source bootstrapping meaning you build with 100% human auditable source code or machine code. The only path to do this today I am aware of is via hex0 building up to Mes and tinycc on up to a modern c compiler: https://github.com/fosslinux/live-bootstrap/blob/master/part...

As far as I know Gentoo, even from their "stage0" still assumes you bring your own bootstrap compiler toolchain, and thus is not self bootstrapping.

replies(1): >>43627808 #
fuhsnn ◴[09 Apr 25 00:33 UTC] No.43627808[source]▶
The fosslinux/live-bootstrap project is more about bootstrapping from minimal binary seed than auditability, for the latter case I'd argue that having a readable C cross-compiler is clearer than going through multiple steps involving several programming or scripting languages.
replies(1): >>43640744 #
lrvick ◴[10 Apr 25 04:55 UTC] No.43640744[source]▶
But how do you build that readable c cross compiler?

Full source bootstrapping is our only way out of the trusting trust problem

replies(1): >>43641210 #
fuhsnn ◴[10 Apr 25 06:25 UTC] No.43641210[source]▶
You bootstrap the compiler with itself and audit whether the compiler binary is exactly the same semantics as its source.

>Full source bootstrapping is our only way out of the trusting trust problem

No, that is just deferring the trust to all the tools and scripts that fosslinux/live-bootstrap project provides.

replies(1): >>43643157 #
akoboldfrying ◴[10 Apr 25 12:33 UTC] No.43643157[source]▶
> You bootstrap the compiler with itself

To be able to do this, you must already have both the source for the compiler and what someone has told you is a binary compiled from it. But what if that someone was lying?

replies(1): >>43645100 #
fuhsnn ◴[10 Apr 25 15:48 UTC] No.43645100[source]▶
Not a programmer, are you? Programmers can fully investigate the compiled binary without anyone even has a chance to lie to them. If a team don't have the ability to audit the decompilation of a 10k LOC C compiler at least once, I doubt their chance against a backdoor hidden in the 100s of steps of https://github.com/fosslinux/live-bootstrap/blob/master/part...
replies(2): >>43647215 #>>43649502 #
lrvick ◴[10 Apr 25 19:22 UTC] No.43647215[source]▶
Not everyone that programs is versed in decompiling, digital forensics, reverse engineering, etc.

Anyway, so your means of forming trust in a compiler faithfully compiling code, is to trust a decompiler to faithfully generate human readable source code followed by a lot of manual review labor repeated by every user that wishes to distrust the maintainers.

Okay, but a decompiler could be backdoored as easily as a compiler to hide malicious code vs inject it .

How do you get a decompiler you trust more than the compiler you are reviewing? Do you decompile the decompiler with itself? Back at the trusting trust problem.

Decompilers are way more complex than anything in the hex0->tinycc bootstrap path.

replies(1): >>43649504 #
fuhsnn ◴[11 Apr 25 01:17 UTC] No.43649504{3}[source]▶
> Anyway, so your means of forming trust in a compiler faithfully compiling code, is to trust a decompiler to faithfully generate human readable source code

No, it is to fully audit the binary of a compiler itself, if you don't trust a decompiler, learn to read machine code, the output from a simple C compiler tend to pretty predictable.

> manual review labor repeated by every user that wishes to distrust the maintainers.

Yes? What's wrong with that? Anyone wishes to distrust, you give them the tools and knowledge to verify the process, the more people able to do this the better.

replies(1): >>43671090 #
1. lrvick ◴[13 Apr 25 08:27 UTC] No.43671090{4}[source]▶
It is going to be a heroic shared win of the entire community if we get people to even do basic review of dependencies in languages where we have the actual source code. Trying to get people to ignore the source code and actually decompile and review every binary they use on every computer they use, including the decompiler somehow, is a lost cause.

We should expect only a few people will review code, if it is drive-by easy to do. That means proving the binaries for sure came from the published commented formatted code, and then go review that code.