Search Mailing List Archives
[liberationtech] [p2p-hackers] Programming language for anonymity network
arnaud.legout at inria.fr
Wed Apr 23 02:06:25 PDT 2014
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
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
when there is not a strong community of developers working on code
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.
More information about the liberationtech