[liberationtech] Communities needed to mitigate heartbleed type bugs

[Jonathan Wilkes]

On 04/23/2014 10:04 AM, Louis Suárez-Potts wrote:
> On 23 Apr  2014, at 08:38, Nick <liberationtech at njw.me.uk> wrote:
>
>> I took the liberty of changing the subject line to something that
>> hopefully somewhat summarises your email.
>>
>> Quoth Arnaud Legout:
>>> As polemical as it can be, deeply-held belief such as "I will always
>>> go for open source code because its security will
>>> be much higher than any closed source counter parts" should be
>>> seriously reconsidered
>>> when there is not a strong community of developers working on code
>>> maintenance.
>> There is a lot of shitty code around. That has always been the case,
>> and will always be so. Anyone who has used the OpenSSL codebase or
>> looked at it even briefly has seen that it's shitty years ago, and
>> probably won't have been too surprised by the recent heartbleed bug.
>> Strong code can and does come out of small teams, including those of
>> one or two people.  I would recommend rather than judging a the
>> quality of a project by whether there is a "strong community of
>> developers" or how the project is financially backed, you take a few
>> minutes to look at the state of the source code. That isn't a deep
>> audit, of course, but can give you a sense for the tastes and cares
>> of the people behind the code.  Needless to say proprietary code
>> which forbids such examination should be avoided, for this and other
>> good reasons.
> When I was "leading" OpenOffice.org I proposed that students, mentored by employed experts and who would probably be project committers (and who might be in fact instructors at colleges and universities), learn about open source collaboration and also programming by working on outstanding bugs and other issues brought to their attention by their teachers and relevant project members. Other large open source projects had people with similar ideas and some, as we did, acted on it.
>
> The idea is not to exploit student labour; and I am aware that a lot of important work actually demands the attention of experts, not students. I am also aware that many professors and teachers are indeed moving to use open source projects' code for their classes. But more could probably be done both to uncover and even fix flawed and hoary code and also teach students open source collaboration techniques. (I also would mean for this to be a global effort, not particular to any one country or region.) Thus, one element of a solution could well be the promotion of known or suspected problem code and architecture for student investigation. Any proposed bug fixes would have to go through the usual (or even more than usual) protocols before inclusion into the accepted codebases.

It sounds like you want to foster a learning environment that has the 
added benefit of improving security software.  But in reality I think 
your proposal would create an environment for rationalizing insecurity.

The "usual" protocols aren't working very well atm-- if they were then 
the Openssl source wouldn't look the way that it does.  If you only keep 
the current barriers to entry for the student coders then at best you're 
no better off than you were before.  Probably you're worse off because 
more people would be submitting code, those people are untrained in the 
field, and the same number of overworked reviewers are now tasked with 
yet more work.

If you implement more barriers for the students than for the experts, 
you immediately create an incentive for both the experts and the 
students to find and exploit the holes in the development process.  
Experts would break it because they'd presumably be the ones expending 
more effort to ensure the students follow the extra protocol cruft; 
students would break it (perhaps accidentally) because they don't yet 
have the expertise to understand the reasoning behind the extra work.  
Welcome to the security line at every U.S. airport.

I'll repeat my suggestion that was previously met with crickets: we 
should wring the last frew drops out of the current expertise devs have 
by requiring a video of rubber duck debugging for major code changes or 
additions.  In the case of Openssl there should have been one first from 
the reviewer, then one posted from the submitter of the patch.

I don't care what hour of the day it is, if a reviewer has to publish an 
oral account of what he/she thinks an implementation of a patch 
_actually_ does, and the submitter then has to do the same, those two 
brains have a way of spotting inconsistencies that typing one's name and 
clicking a button has tended to miss.

-Jonathan