The German government paid $500,000+, to Arch Linux, to re-write Arch Package Management in Rust. Is Germany hoping to inject backdoors, or other spyware, in...
Checksum compared to what though? Like you have to compile the code first, and if your compiler is compromised then all the code it outputs is also consistently compromised. Checksum isn’t going to help you here. Literally the only way around this is to build a compiler from scratch in assembly, then use that to compile your code.
Like I said, the only way you could really trust it is if you’re not using a compile to make it. You have to write a compiler directly in assembly and then use that to compile everything else.
What I’m saying is there is no need to write a whole new compiler in assembly, check out the bootstrapping article I linked.
Or, if there is some uncompomised older compiler version A, and a compromised version B built with A, then the source code for B can be fed to A to create a clean version. As in it might be hard to try to poison the supply chain now, if they haven’t already. We can’t be sure it isn’t already poisoned, but if it actually isn’t it’s possible to catch such an attack.
The key problem is knowing whether something is compromised or not though, that why you can’t use an existing compiler if you want to be sure. Meanwhile, bootstrapping involved building a minimal core in assembly and then progressively compiling the compiler using itself. That’s basically how you build a whole new compiler starting with assembly.
Haha yeah it’s not great. Now that I thought about it some more, I wonder if you could use decompiling to verify that the compiler is doing what it says it does. If you compile a minimal program, and then decompile the assembly, you could see if there are any instructions that shouldn’t be there. It wouldn’t be trivial, but seems like it is a possible way to check that the compiler isn’t injecting something weird.
The compiler can introduce vulnerabilities only on some specific instructions, although it makes it difficult to propagate it further to new compilers.
I don’t know much about Rust, but from the discussion here, I get that it only has one compiler implementation and that it can’t be verified. So anything compiled with it is, technically, not fully verifiable. It doesn’t matter if the compiler I have on my computer is exactly the same as the one provided by the Rust devs (which is what checksums do), if the one provided by them is already tampered with.
Right, but really the problem goes beyond Rust itself. Other compilers could be compromised as well. Of course, when you have multiple compiler implementations, the situation is better because you can compare differences in binaries they output. Another approach you could take is to make am minimal program and decompile it, and see if there’s anything funky.
Can you explain how evaluating checksum doesn’t counter this? I don’t know much about this topic but am quite intrigued.
Checksum compared to what though? Like you have to compile the code first, and if your compiler is compromised then all the code it outputs is also consistently compromised. Checksum isn’t going to help you here. Literally the only way around this is to build a compiler from scratch in assembly, then use that to compile your code.
Compile the compiler? I presume there is some version that isn’t compomised? Or go all the way back to some bootstrapped c compiler?
Like I said, the only way you could really trust it is if you’re not using a compile to make it. You have to write a compiler directly in assembly and then use that to compile everything else.
What I’m saying is there is no need to write a whole new compiler in assembly, check out the bootstrapping article I linked.
Or, if there is some uncompomised older compiler version A, and a compromised version B built with A, then the source code for B can be fed to A to create a clean version. As in it might be hard to try to poison the supply chain now, if they haven’t already. We can’t be sure it isn’t already poisoned, but if it actually isn’t it’s possible to catch such an attack.
The key problem is knowing whether something is compromised or not though, that why you can’t use an existing compiler if you want to be sure. Meanwhile, bootstrapping involved building a minimal core in assembly and then progressively compiling the compiler using itself. That’s basically how you build a whole new compiler starting with assembly.
Thanks for the explanation. I don’t like this. Lmao.
Haha yeah it’s not great. Now that I thought about it some more, I wonder if you could use decompiling to verify that the compiler is doing what it says it does. If you compile a minimal program, and then decompile the assembly, you could see if there are any instructions that shouldn’t be there. It wouldn’t be trivial, but seems like it is a possible way to check that the compiler isn’t injecting something weird.
The compiler can introduce vulnerabilities only on some specific instructions, although it makes it difficult to propagate it further to new compilers.
Good point, verifying a disassembled binary wouldn’t exhaustively prove the compiler is safe.
I don’t know much about Rust, but from the discussion here, I get that it only has one compiler implementation and that it can’t be verified. So anything compiled with it is, technically, not fully verifiable. It doesn’t matter if the compiler I have on my computer is exactly the same as the one provided by the Rust devs (which is what checksums do), if the one provided by them is already tampered with.
Right, but really the problem goes beyond Rust itself. Other compilers could be compromised as well. Of course, when you have multiple compiler implementations, the situation is better because you can compare differences in binaries they output. Another approach you could take is to make am minimal program and decompile it, and see if there’s anything funky.