Hacker News Reader

Comment by zmguy | Hacker News Reader

Stiff, I think you answered your own question. Intel HIRES them, open source projects don't generally hire people. They sit around and wait for someone to contribute. Are you truly surprised that a volunteer created software is not as rigorously tested as software created by Intel?

View on HN

I had some problems expressing what bothers me clearly and edited the comment heavily, perhaps it makes more sense now. You're right it is not that surprising, but it's still disappointing that even the most rudimentary best practices are not adopted. Have a look at sqllite for comparison, also an open source project, also in C, certainly less mission critical, and what a difference:

https://github.com/smparkes/sqlite/tree/master/test

https://github.com/smparkes/sqlite/blob/master/src/rowset.c

sqlite does not seem less mission critical to me, and definitely relied on funding:

"D. Richard Hipp designed SQLite in the spring of 2000 while working for General Dynamics on contract with the United States Navy.[7] Hipp was designing software used on board guided missile destroyers" -- http://en.wikipedia.org/wiki/Sqlite#History

I work for a very large company that relies on a fork (with contributions back upstream) of SQLite for a majority of its massive enterprise SOA. It is not just unpaid volunteers keeping that project going.

What do you consider when choosing SQLite issues to assigns resources? I would guess it would start with issues relevant to your roadmap. If that's the case with most enterprise FOSS contributors, they most likely trusted the features of OpenSSL they were using. Thus no reason to go poking around that section of the code. It's understandable why a team might choose to not perform an ad-hoc security audit of features that pass specs, even more so when such an audit requires niche expertise. We can hope this bug changes that attitude and more enterprises with the resources and knowledge start performing security and encryption audits. Just as your buildings have security guards, we need proactive and preemptive audits of at least the most common libraries is use, flagging of software that implement unaudited encryption libraries. A Travis CI like badge on GitHub for these audit metrics would bring attention to the problem. We could call it EncryptCI. Maybe this already exists?

Being FOSS doesn't have to mean relying on volunteers. Linux is mostly written by paid developers; why isn't OpenSSL, considering its reach in the commercial world?

Slightly off topic, but do you know whether the paid developers of Linux work on the core kernel, or on device drivers?

Both, as they provide the bulk of the code. It would be more illuminating to examine where the unpaid volunteers contribute. My guess would be device drivers, but I don't know.

This has some information although not exactly what you wanted to know:

http://lwn.net/Articles/579081/

A number of the OpenSSL team are employed by large tech companies to work on OpenSSL. For example Bodo Möller and Ben Laurie work for Google.

This bug was in fact discovered by a Google employee: https://www.openssl.org/news/secadv_20140407.txt

Reply on news.ycombinator.com