[liberationtech] [p2p-hackers] Programming language for anonymity network

[Arnaud Legout]

Hi,

Le 18/04/2014 20:50, michi1 at michaelblizek.twilightparadox.com a écrit :
> On 10:26 Fri 18 Apr     , Stevens Le Blond wrote:
>>   Specifically, we are concerned that large runtimes
>> may be difficult to audit. A similar argument may apply to other
>> interpreted languages.
> I do not think that the C toolchain is easy to audit either. I would just
> focus on something which is open source and in wide use. In this case,
> somebody who has a backdoor in the runtime or toolchain probably has a
> backdoor to the system either way.
>

like anybody who as worked seriously in computer security and privacy, I 
have been an advocate for
open source code, arguing that it makes security stronger because 
anybody can look at the code.
Obviously, widely used systems (and in particular security related 
systems) are audited from time to
time by experts, which improves significantly trust compared to closed 
source systems.

Then, I looked at the git repository of the OpenSSL project, arguably 
one of the most critical
and one of the most widely used piece of code (by the way, who went 
further than the numerous copy/paste
pseudo journalistic/expert articles of the Heartbleed bug). I was 
convinced that this code is maintained by a team
of experts with an involved commit process. The code just speaks for 
itself, OpenSSL has been maintained by a single
guy for years. This guy does not receive any financial support, so he is 
working on OpenSSL on his spare time.
This is an insane (and a widespread) problem in the open source community.

A Ph.D. student proposed the hearbeat code following his RFC on this 
subject (RFC 6520). The maintainer of the OpenSSL
code committed the hearbeat code (containing the heartbleed bug) on the 
31st of December 2011. It is obvious
from the code that there is a severe bug. By obvious, I mean that the 
bug is described in the RFC (that is only 6 pages,
so quite fast to go through), a solution is proposed, but this solution 
is not implemented in the code that is committed.
Of course, as obvious as it is, it would require for any expert hours to 
audit and to spot the bug. Who can afford this
extra time when the maintenance is on your spare time.

I am almost certain (but may be I am once again wrong) that (at least a 
few) security agencies and
blackhats are looking that the commits of such critical codes. So this 
bug might have been exploited
for years. In this specific case, open source code did not improve the 
security, but on the opposite compromised
the security and privacy of probably each and every Internet users.

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.

I am still convinced that open source is the best option when backed 
with a strong team of developers, but
the sad truth is that numerous open source projects we are all daily 
using are either no more maintained
or maintained by a single person on her spare time.

Arnaud.