Few Words on Collaborative Software Development
Mauro, SHUT THE FUCK UP!
It's a bug alright - in the kernel. How long have you been a
maintainer? And you *still* haven't learnt the first rule of kernel
If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs. How hard can this be to understand?
The above extract is Linus Torvalds’s infamous explanation to Mauro Carvalho Chehab on the why, unintuitively, fixing a bug that results in upstream breaks is not a good idea.
The answer to the question: what’s the right thing to do becomes even more controversial when user space break happens, because of a zero day exploit.
The classic Bitcoin example is when Bitcoin Core devs find something that affects other altcoins: Should they notify altcoin developers about it before the risk is mitigated? If your answer is yes, then which altcoins? There are thousands of cryptocurrencies in existence, most of them were created by the very same people, who’d be the most likely to be willing and able to exploit the vulnerability in the first place.
Bitcoin Hardware Wallet Ecosystem
What sparked me to write this article is recent tensions regarding hardware wallets. In order to understand it, it’s important to understand how various ecosystem participants integrate with each other:
The three most popular hardware wallets all directly integrate to Electrum.
They integrate to Wasabi, BTCPay and Core through HWI.
Ledger and Trezor directly integrate to their own software wallets.
Events in Chronological Order
- A security bug that affects all hardware wallets was disclosed to Trezor and Ledger (and some other hardware vendors, but for the sake of simplicity, I’ll omit them until the ending thoughts.)
- Trezor implemented a backwards incompatible fix in their hardware.
- Ledger implemented the same fix, but allows the user to use un-updated applications with a warning because they assessed the bug low severity.[src]
- Trezor and Ledger implemented compatibility in their software wallets.
- Trezor implemented compatibility in Electrum.
- Trezor and Ledger released their fixes and disclosed the bug.
- Coldcard fixed the bug in their hardware in a backwards compatible way, as their assessment was the same as Leder’s was: the bug is low severity.
- BTCPay is architecturally incapable to implement compatibility, thus it is dropping Trezor support.
- HWI and Wasabi are currently implementing compatibility.
- Electrum did not release the fix yet. (Not sure they will anytime soon as I think they don’t plan to release until their Lightning Network integration is done, though the current situation may change this.)
- (Bitcoin Core’s proper HWI support isn’t finished yet.)
Moral of the story?
Ledger fixed the bug in a backwards compatible way, so they had no reason to disclose it to upstream ecosystem participants, as they don’t break them. Trezor fixed the bug in a backwards incompatible way, so they should’ve disclosed the bug upstream, right? Well, it’s complicated. They prioritized security over not breaking user space.
What about sidestream? Put yourself into the shoes of hardware wallets those knew about the bug, and remember my Bitcoin vs altcoins example in the beginning: If you favor Bitcoin Core not disclosing zero day vulnerabilities to altcoins, then wouldn’t it be contradictory to favor Trezor and Ledger disclosing zero day vulnerabilities to other hardware wallets? Consider that there are numerous hardware wallets out there. So should Trezor and Ledger disclose zero day vulnerabilities to every single hardware vendor? Or should Trezor at least disclose them upstream to HWI, Wasabi, BTCPay and Core? Or should HWI, Wasabi, BTCPay and Core work harder to earn Trezor’s trust first?
These are far from easy questions, and I really don’t have good answers. Furthermore this isn’t limited to the Bitcoin ecosystem, but these are issues effecting many other areas of computing, see my introductory Linux kernel example.
On the bright side, we, software and hardware developers are well known for our social skills, so you can expect a quick, clean and satisfactory resolution of all these hard problems :)
by the author.