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.
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?
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...
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.
> 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.
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.
As another commenter observed, having to trust a decompiler doesn't reduce the amount of trust you need to provide, it increases it. Reducing the amount of trust is our high-level goal, remember?
But let's not focus too hard on the logic side of your argument. The part that really convinced everyone that you're right was your opening statement, "Not a programmer, are you?". From that moment it was clear that you were taking the discussion to a higher plane, far above boring everyday logic.
Like a superhero, really. At least, that's how I picture you.
That was the response to your "what someone has told you is a binary" argument, if you learnt the basics of programming, you will know it's just a hexdump away to verify a binary, there's no one else in the room to tell you anything, you hit compile and see the result yourself, it's simple, direct and intimate. Yeah you could say it feels like a superpower, and it's a skill everyone can learn.
So you just dump hex and know exactly what a program does, and can quickly understand if uses good entropy sources, uses good cryptography choices, etc in the same amount of time or less time than you could read the published source code to verify the same?
If you can do that, you are the only one alive that can.
