3 ms·

Assuming you: - trust your compiler and linker - trust your tar extractor / package manager / whatever - trust your editor - trust your http library (or wha

by kibibu 12y ago

Assuming you: - trust your compiler and linker - trust your tar extractor / package manager / whatever - trust your editor - trust your http library (or whatever you used to download/distribute the code)

Nursie 12y ago
>> - trust your http library (or whatever you used to download/distribute the code) This can be overcome with signing. We're all well aware of how deep this rabbit-hole goes, however that doesn't mean that it's a good idea to throw all trust away.
rlpb 12y ago
It comes down to trusting two key things. Trusting your initial distribution download (which contains the package signing keys), and trusting the toolchain (in a Reflections on Trusting Trust way). But the deeper you go, the harder it is for malicious code to reside there. In theory it's possible, but in practice I'd like someone to show me some code somebody could have written into the toolchain a decade ago, without hindsight, which could still exist today. Whichever way, it's clearly far tougher for a malicious actor to compromise a system by injecting something into a distribution ecosystem than it is to inject a signed-by-unknown-reputation binary-only package into the Maven ecosystem.
davexunit 12y ago
This is where reproducible builds [0] come in. We can trust our binaries much more if the same build inputs yield the same build output. Building on that, could we find a fixed point where the OS builds the exact same bootstrap binaries that were used to bootstrap the OS to begin with? [1] That would give us even more confidence that the binaries we're using are as they should be. Interesting place for experimentation. [0] https://reproducible.debian.net/reproducible.html https://reproducible.debian.net/reproducible.html [1] https://gnu.org/software/guix/manual/html_node/Bootstrapping.html#Building-the-Bootstrap-Binaries https://gnu.org/software/guix/manual/html_node/Bootstrapping...
vacri 12y ago
Trust isn't binary. It's a scale of weighted risks.

by kibibu 12y ago

Nursie 12y ago

>> - trust your http library (or whatever you used to download/distribute the code) This can be overcome with signing. We're all well aware of how deep this rabbit-hole goes, however that doesn't mean that it's a good idea to throw all trust away.

rlpb 12y ago

It comes down to trusting two key things. Trusting your initial distribution download (which contains the package signing keys), and trusting the toolchain (in a Reflections on Trusting Trust way). But the deeper you go, the harder it is for malicious code to reside there. In theory it's possible, but in practice I'd like someone to show me some code somebody could have written into the toolchain a decade ago, without hindsight, which could still exist today. Whichever way, it's clearly far tougher for a malicious actor to compromise a system by injecting something into a distribution ecosystem than it is to inject a signed-by-unknown-reputation binary-only package into the Maven ecosystem.

davexunit 12y ago

This is where reproducible builds [0] come in. We can trust our binaries much more if the same build inputs yield the same build output. Building on that, could we find a fixed point where the OS builds the exact same bootstrap binaries that were used to bootstrap the OS to begin with? [1] That would give us even more confidence that the binaries we're using are as they should be. Interesting place for experimentation. [0] https://reproducible.debian.net/reproducible.html https://reproducible.debian.net/reproducible.html [1] https://gnu.org/software/guix/manual/html_node/Bootstrapping.html#Building-the-Bootstrap-Binaries https://gnu.org/software/guix/manual/html_node/Bootstrapping...

vacri 12y ago

Trust isn't binary. It's a scale of weighted risks.