Software flaws don't negate "many eyes" in open source
Bugs in Linux, OpenBSD are just human nature, not a flaw in the system
The allegations from Greg Perry regarding backdoors allegedly placed within OpenBSD about a decade ago seem to be shifting more and more into the realm of fantasy as each day goes by.
To date, Perry has not responded to my inquiry regarding his Dec. 11 e-mail to OpenBSD founder Theo de Raadt, nor to my knowledge has he responded publicly anywhere else. Meanwhile, the two (or three, depending on how you count it) people named in Perry's message to de Raadt as parties to this supposed backdoor activity, Scott Lowe and Jason Wright, have denied their involvement--the latter within the same [openbsd-tech] thread that started all this.
[ See also: OpenBSD/FBI allegations denied by named participants ]
Since no one has heard any more from Perry, I will decline to speculate why he made these accusations, except to note that sometimes silence can speak volumes, and this may indeed be one of those instances.
While the accusations fly, de Raadt has indicated at least to one media outlet that an audit of this part of the OpenBSD code has found some bugs.
"We've been auditing since the mail came in! We have already found two bugs in our cryptographic code. We are assessing the impact. We are also assessing the 'archeological' [sic] aspects of this," de Raadt told iTWire.
It is not clear whether these bugs would allow the insertion of a backdoor or sideways entry-point into an OpenBSD system, nor if, based on de Raadt's statements to iTWire's Sam Varghese, these are the only bugs in this part of OpenBSD.
My colleague Glyn Moody tapped on any possible existence of such bugs in OpenBSD--planted or not--as a fundamental problem with one of the core tenets of free and open source software (FLOSS) development:
"This serious stuff--not just because it means that open source code may have been unwittingly complicit in who knows how many acts of surveillance, but because it calls into question the basic development model of open source, which places a high value on trust. If it is confirmed that hackers put a backdoor in open source code for money--and some doubts have already been expressed--then that will cast some doubt on that principle.
"Moreover, if eventually such backdoors are found, it will raise questions about the whole 'given enough eyeballs, all bugs are shallow' philosophy. It's true that backdoors aren't exactly bugs, but there is still the issue of how something this serious--if confirmed--could lay undetected for a decade," Moody wrote.
The "many eyes" principle is one of free and open source software's biggest advantages: bugs are easier to find when more people are looking for them. From a sheer numbers standpoint, this seems to make perfect sense. So why do developers find bugs in OpenBSD, Linux, or any other FLOSS-based project?
My opinion about this found some crystallization during, of all places, a morning coffee meeting this week with one of my pastors.
In our conversation, the topic of pastoring came up in a broad, historic sense. I won't get into this too much, but the early Christian church was not the pastor/minister/priest-centric organization it tends to be today. Instead, early Christians got together to worship in more communal groups, where individuals had different roles, but not with the centralization we have today. Somewhere along the way ("blame Constantine," my friend told me), the notion of pastor-as-leader and all the ceremonial (and temporal) powers that go with it came to be the common church management structure.
I ventured the opinion that it's part of being human: many organizations, be they a religion, a political body, a business, or even the sekrit treehouse clubs we had as kids, seem to gravitate towards a top-down centralized management structure. We often seem to put people in charge.
In the context of our conversation, I said to my friend that in a church (or any religious organization), maybe it's easier to let pastors be in charge. Let him or her take care of the faith stuff, the reaching out to help others, and caring about my fellow parishioners so I don't have to. It occurred to me then that this is likely why we tend to let others be leaders of any group: I'll let you handle keeping my city running, Your Honor, so I don't have to worry about it. Let that other parent run the PTA bake sale, so it's not on my plate.
We won't always be so deliberate about it, either: sometimes we just assume that someone else will deal with the problem.
This is the core of my response to Mr. Moody: there is nothing wrong on paper with the "many eyes" principle, but because of human nature, it can never be perfect. A developer may assume a maintainer of a particular piece of code has already checked it for bugs, or knows about a just-discovered bug already. Or a maintainer may assume that code is thoroughly bug-free and commits it. It could be apathy or false assumption, but that's how errors creep into any system, even the meritocracies that form many of the FLOSS communities.
I would submit, though, that while as flawed as any human concept will be, the "many eyes" approach is still a better way than a proprietary approach. While numbers aren't everything, as we've just seen, they still count for something.