On Thu, Apr 10, 2014 at 3:29 PM, Edward Ned Harvey (lopser) <lop...@nedharvey.com> wrote: >> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] >> On Behalf Of Stephan Fabel >> >> Question: given this issue, would anyone recommend switching SSL >> libraries?What about PolarSSL, for example? > > Depends. Which one sees more widespread usage, more contributors > maintaining, has greater maturity?
I believe that code maturity (age) is not as correlated with security as people often seem to believe. Programs that have been used for a long time in multiple environments due tend to have fewer bugs (or at least fewer bugs about which people care). The problem with security bugs is that all it takes is one and anything close to normal use will generally not trigger them. It's only through deliberately bizarre action that most security bugs are invoked. A million regular users can help to make a program more reliable (due to bug reports), but they won't make it more secure. (Except to the extent that those million users attract more attackers.) As a result, I would argue that if the concern is security; it isn't how old the code is that matters. It is the explicit effort taken to analyze the code for security problems that is important. Whether that analysis is done by developers or by attackers doesn't matter (as long as security problems are noted and fixed). Unfortunately though code doesn't stand still. A lot of analysis of the previous version doesn't mean much about the security of the current version. As in the case of OpenSSL, a poorly implemented new feature could change the status of a program from secure to insecure. But a completely broken new feature won't normally turn a reliable program into garbage. Bill Bogstad _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
