On 04/23/2014 10:04 AM, Louis Suárez-Potts wrote:
On 23 Apr 2014, at 08:38, Nick <[email protected]> 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
--
Liberationtech is public & archives are searchable on Google. Violations of
list guidelines will get you moderated:
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change
to digest, or change password by emailing moderator at [email protected].
