pull down to refresh

I find Lunduke's reasoning quite plausible here: https://x.com/LundukeJournal/status/1986142018418966545
A self-hosting compiler is an existential threat to the Bitcoin community. If a zero-day hidden in a compiler (which happen to be maintained by communists) hits us, we're fucked.
Are measures being taken on projects like LDK, LNDK, or Ord to name a few? What options does the Bitcoin community have?
Well, there is work on a Rust compiler on top of GCC: https://github.com/Rust-GCC/gccrs
GCC Front-End For Rust
This is a full alternative implementation of the Rust language on top of GCC with the goal to become fully upstream with the GNU toolchain.
reply
Just when I was getting into Rust :|
The problem he brings up applies to lots of different software and hardware at this point, no? People trust their vendors not to put backdoors in (lol), and most programming languages and runtimes are vulnerable to some degree, aren't they? Especially when it comes to package / dependency management, any software that is ergonomic and useful could be an issue with its dependencies.
reply
100 sats \ 0 replies \ @optimism 5h
It's not the end state, just needs work. A lot.
reply
179 sats \ 7 replies \ @optimism 7h
Trust is key.
Determining which software developers can be trusted is challenging.
What makes that determination easier... is when software developers tell you, point blank, that you cannot trust them.
It then continues to make assertions about what actions from developers would implicitly point to "them telling you that you cannot trust them". But a trustworthy dev would:
  1. Tell you straight to not trust them, and
  2. Point you to the process they have in place and ask you for feedback on that
The problematic assertion though is their first. "Trust" as depicted here has nothing to do with actual trust, it's to do with not doing your due diligence. Because if the (political) behavior of individual developers or even groups of them influences your trust in the product, then you're approaching this the wrong way; either because you don't have the skills, or because you don't want to spend time.
The reason for that is that trust is earned and therefore it's more efficient to trust a process, and not an individual, as individuals have higher churn than (established/institutionalized) processes. The way a process gets trust is because you audit the process and in open source, ideally you do that by participating in it.
What options does the Bitcoin community have?
Participate in their development process. Don't trust, verify.
reply
100 sats \ 1 reply \ @Scoresby 1h
if the (political) behavior of individual developers or even groups of them influences your trust in the product, then you're approaching this the wrong way; either because you don't have the skills, or because you don't want to spend time.
This is well put. If a zero-day was hidden in a compiler which happens to be maintained by Satoshi himself, we are still fucked.
reply
0 sats \ 0 replies \ @Row OP 1h
Yes, but only if we're using a lang that doesn't have multiple compiler implementations, which is not the case for traditional system langs.
reply
100 sats \ 4 replies \ @Row OP 7h
What options does the Bitcoin community have? Participate in their development process. Don't trust, verify.
Check Ken Thompson's "Reflection on Trusting Trust".
Auditories are out of the question, the problem is precisely that since the compiler is self-hosted, such attack is not easily auditable, the scheme can hide malicious code without requiring to publish a change in the source, you'd have to audit each and every binary release of the compiler.
It would be kind of solved with a second Rust compiler.
reply
"Reflection on Trusting Trust"
I'm familiar with it.
It would be kind of solved with a second Rust compiler.
Only if you use it.
reply
100 sats \ 2 replies \ @Row OP 6h
I'm familiar with it. It would be kind of solved with a second Rust compiler. Only if you use it.
That's the point, having a second compiler would allow you as an auditor to perform the cross-check.
In the current state, you can't, and have to resort to auditing every single binary.
reply
0 sats \ 1 reply \ @optimism 6h
I'm not arguing that you're wrong - to the contrary - I'm answering your question to the how: If you really want to use Rust, and there is no second compiler or at least an -O0-like bootstrap compiler to compile a compiler, then you have to build said compiler and use it.
I simply read all this as "in the current state you cannot use it if you have any meaningful security requirement". But the compiler isn't even the biggest problem: Cargo is. If besides the compiler, you also have to audit every diff of every release of every crate you use, would you still use Rust? Would it still be as great a language as the bird app cult likes us to believe? Have you tried reviewing crates? I have; results vary.
Remember "we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL", and GMax explaining it a bit. If we take this as baseline Bitcoin developer mindset, then we can be pretty sure that we need some effort put into rust if we really want to use that.
reply
0 sats \ 0 replies \ @Row OP 1h
I see, that makes a lot of sense. Thanks for the links.
reply
140 sats \ 1 reply \ @k00b 10h
Ideally we’d have a bootstappable build like this guy was working on.
reply
Thanks for that bootstrappable.org link
reply
13 sats \ 5 replies \ @Nodii 10h
reply
Haha @joshmo_dev's reply to this unhinged paranoia rant is most apt.
The Rustic compiler is also a community maintained open-source project, with 148 contributors. The risk of a back-door slipping in with nobody knowing is as low as it is for any project. The motivation to move to Rust is because it has many benefits over other languages, especially for performance and security.
reply
0 sats \ 2 replies \ @Nodii 10h
You don't happen to be one of the 148, right? If you are, why haven't you disclosed it? And if you aren't, do you even know one of those 148?
reply
No to all; I just looked at their Github. Knowing them is irrelevant. Think of how many millions of people have been involved in the tech stack transmitting your every keystroke from your fingers through the Internet to this retarded thread.
reply
8 sats \ 0 replies \ @Row OP 8h
You don't understand the problem. Please study computer science, or at least get "Reflections on Trusting Trust".
reply
0 sats \ 0 replies \ @Row OP 10h
Learn computer science please.
reply
I wouldn't trust anything that guy is saying. As far as I know there is a bootstrap for Rust through mrustc, gcc, and finally stage0. Bitcoin Core takes a lot of in pride in only shipping a binary that is built from a fully transparently bootstrapped toolchain using a similar chain of tools.
reply
0 sats \ 1 reply \ @Row OP 1h
I wouldn't trust anything that guy is saying. As far as I know there is a bootstrap for Rust through mrustc, gcc, and finally stage0. Bitcoin Core takes a lot of in pride in only shipping a binary that is built from a fully transparently bootstrapped toolchain using a similar chain of tools.
Lunduke exagerates everything, but that's besides the point, his argument is one logical, not a sensationalist one. Notice that this is not about Core, but the things we run algonside Core, such as LDK, LNDK, Ord, or, why not... even cargo-binutils.
reply
I only mention Core, because it uses the same bootstap chain, that you could use for LDK, LNDK, Ord, etc. Maybe it would have been better to mention Liana wallet, which is Rust-based and uses this bootstrap chain too.
reply
0 sats \ 0 replies \ @panter 10h
Satanic :(
reply
Alt link, for those who don't want to be on X: https://xcancel.com/LundukeJournal/status/1986142018418966545
reply