David A. Wheeler

> Interestingly, there was a lot of speculation and misinformation. So even on Hacker News, this topic is still only vaguely understood.

This is not a new revelation, and a similar vulnerability is discussed in Mastering Bitcoin: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc#the-importance-of-randomness-in-signatures

> The way I understand it, it makes it completely impossible to use Bitcoin in a trustless way. Even with an air gapped hardware wallet, you are always at the mercy of the wallet manufacturer and the delivery chain that gets the wallet to you. If it gets swapped out on the way to you, you are at the mercy of whoever swapped it out.

Bitcoin's threat model assumes assumes your client software follows specifications. Airgapped hardware wallets aren't designed to eliminate "Reflections on Trusting Trust". Assuming your scenario, the attack can be tested in a similar way to that outlined in "Fully Countering Trusting Trust through Diverse Double-Compiling" (https://dwheeler.com/trusting-trust/).
Under a better defined threat model, a construction can be made to effectively prove any data exfiltration scenario to be false.

In conclusion the issue your proposing is not an issue with bitcoin, but with computation in general. The word trustless in the context of cryptocurrencies has slowly been taken out of the context "trusted third parties" and evolved into an epistemological rather than pragmatic issue.

>> The cost of Linux kernel development alone has been estimated at a few $B (https://dwheeler.com/essays/linux-kernel-cost.html), current figure is probably over tens of billions.

I followed your link, but it doesn't seem to bear out upur assertion. The two numbers mentioned in the article are 176 mil and 612 mil. Mind you those weren't an estimate of cost, but rather an estimate to replace. Article is dated 2004, with an update in 2011.

Using the lines-of-code estimation it crossed a billion in 2010 - again to replace. That has no relation to what it did actually cost.

Getting from there to "tens of billions" seems a stretch. Assuming a bottom value in your estimate of 20 billion, and assuming a developer costs a million a year, that's 20 000 man-years of effort. Which implies something like 2000 people (very well paid people) working continuously for the last decade.

Which seems, well, unlikely.

Formatting doesn’t remove bugs, but it’ll help you detect them. Linted code helps you scan the code faster and provides valuable pattern recognition, allowing us to detect common mistakes.

There have been numerous bugs caused by incorrect code formatting, most notably an SSL security bug from 2014: https://dwheeler.com/essays/apple-goto-fail.html

Another reason for formatting is the “minimal diff” paradigm. If a formatting rule would not be followed, in the next commit hitting this code, the format would also be affected, causing a larger diff than necessary.

There are other reasons for simple format linting, but the reasons above are the most profound.

Lastly, formatting is part of a range of static code analysis tools. Generally, formatting inconsistencies are the easiest to detect and resolve, as opposed to more sophisticated tools.

Maybe not favorite but "most memorable": "CVE-2014-6271: Remote code execution through bash" [1]

The top comment when I first saw it was, "If you are responsible for the security of any system, this is your immediate, drop-everything priority." [2]

Shellshock just kept going, and going, and for days you didn't know what was coming next. I suppose it's unfair to real PTSD victims to say this, but sometimes I feel like I have a little PTSD from that incident. I can only imagine what people at the center of it were going through.

My favorite blow-by-blow account was David Wheeler's essay [3] [4].

[1] https://news.ycombinator.com/item?id=8361574
[2] https://news.ycombinator.com/item?id=8361871
[3] http://www.dwheeler.com/essays/shellshock.html
[4] https://news.ycombinator.com/item?id=8428644

My favorite resource about software innovation is David A. Wheeler's list of the most important software innovations.[1]
Most of the items on the list are from the 60s, 70s, and 80s, and 90s; just one is from the past ten years (Wheeler was at first ambivalent about even adding it). He also makes the point that it is okay not to be innovative, and quotes Linus Torvalds:

"People want to hear about the one big idea that changes the world, but that’s not how the world works. It’s not about visionary ideas; it’s about lots of good ideas which do not seem world-changing at the time, but which turn out to be great after lots of sweat and work have been applied."

[1]http://www.dwheeler.com/innovation/innovation.html

Oh, you explaining it is a nice thing to do. I was just showing what was actually necessary to meet the intended goal since that's my field. I learned a lot of the problems from people like Myers who wrote the book on subversion back in 1980. Current approaches still aren't as thorough as what they were doing in the 1970's-1980's.

https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/myer80.pdf

If it's about repos, I recommend David A. Wheeler's page on SCM security since following it eliminates most of the risks.

https://dwheeler.com/essays/scm-security.html