Open Source Values: Transparency in the Post-Snowden Era
First, let me add to the chorus of praise for Coding Freedom. The book gives an insightful and sympathetic take on geek culture generally, and on the social dynamics and governance of the Debian community specifically. I was especially charmed by the section on geek humor.
The book rightly emphasizes the values of freedom (as in speech) and transparency in Debian. I want to talk about transparency, which has taken on added importance in light of the recent NSA revelations.
Now that we know about the NSA program to “[i]nsert vulnerabilities into commercial encryption systems, IT systems, networks, and endpoint communications devices” we have to wonder whether the platforms we are using have built-in back doors. So we care a lot more about software transparency.
Debian is about as transparent as a large software project can be. The code, the bug/issue tracker, and most of the email conversations among the developers are all public, going back to the early days of the project. So we can look not only at the evolution of the code itself, but also at the reasons given for the changes that were made.
What makes this especially interesting for Debian is that there was a serious security vulnerability in a core component of Debian, which was inserted by a developer and stayed in place for quite a while before another developer discovered and fixed it. The bug made Debian’s pseudorandom number generator (PRNG)—which is the source of virtually all encryption keys used by Debian users and services—vulnerable to a simple attack. Anybody who knew about the bug could recover others’ secret keys without much trouble.
This was a serious failure of Debian’s quality control process, but we shouldn’t jump to the conclusion that alternative approaches to software development have stronger defenses against this kind of failure. Debian’s transparency made it impossible to hide the flaw and forced a conversation about quality control afterward.
In hindsight, one can’t help wondering whether the Debian flaw was one of those NSA back doors we have been reading about. The nature of the flaw raises suspicion. A simple and superficially harmless-looking change to the code introduced a vulnerability that was difficult to find but easy to exploit if you knew about it—just what you’d expect from an inserted back door.
Fortunately, we have the full record of who introduced the flaw and what was said about it at the time, not to mention the postmortem discussion after it was discovered. My student Josh Kroll has examined the record in detail, and he is convinced that this was a simple error and not a deliberate back door. Without a detailed, contemporaneous record, there’s no way he could have answered this question with any confidence.
The lessons of the Debian random number flaw are worrisome. Although this wasn’t a back door, the fact that this flaw could be created, inserted into Debian and remain there undiscovered for as long as it did, teaches us that it was feasible to backdoor Debian at that time. It’s probably still feasible today. There could be an undiscovered back door now.
There’s suggestive evidence that somebody tried to insert a back door into the main Linux kernel back in 2003. It looked like a programming error; and it would have created a vulnerability that was difficult to discover but easy to exploit if you knew about it. Sound familiar? Fortunately Linux developers spotted the problem and kept the harmful code from shipping.
Linus’s Law says that “given enough eyeballs, all bugs are shallow.” Transparency makes it possible for many eyeballs to scour the code for back doors. But something more is needed to make sure that the army of coders is actually out in the field hunting for bugs.