[liberationtech] Programming language for anonymity network

[Peter Lindener]

Michael-

    You have a point C++ in the raw would be a big mistake, Then I was
suggesting a Safe, compiler enforced subset. of C++... (still to be
determined)...

    -Peter



On Tue, Apr 22, 2014 at 9:54 AM, Michael Rogers <michael at briarproject.org>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Stevens,
>
> I think it would be irresponsible to start a new project in C or C++
> given the enormous number of security issues caused by memory handling
> bugs in C and C++ code. Here's a quote from a Debian security advisory
> I just received, which is typical of these advisories:
>
> "Multiple memory safety errors, out of bound reads, use-after-frees
> and other implementation errors may lead to the execution of arbitrary
> code, information disclosure or denial of service."
>
> These are entire classes of bugs that don't exist in safer languages.
> Avoidable bugs like this are found every day in widely used, open
> source software. Software that isn't widely used and open source
> presumably has a similar density of bugs, but they're undiscovered or
> undisclosed.
>
> C and C++ programmers seem to think that memory handling bugs are
> something that happens to other people. They're not. Every programmer
> in every language makes mistakes, but in C and C++ simple mistakes can
> have subtle and disproportionately serious consequences.
>
> Cheers,
> Michael
>
> On 18/04/14 09:26, Stevens Le Blond wrote:
> >
> > Hello,
> >
> > We are a team of researchers working on the design and
> > implementation of a traffic-analysis resistant anonymity network
> > and we would like to request your opinion regarding the choice of a
> > programming language / environment. Here are the criteria:
> >
> > 1) Familiarity: The language should be familiar or easy to learn
> > for most potential contributors, as we hope to build a diverse
> > community that builds on and contributes to the code.
> >
> > 2) Maturity: The language implementation, tool chain and libraries
> > should be mature enough to support a production system.
> >
> > 3) Language security: The language should minimize the risk of
> > security relevant bugs like buffer overflows.
> >
> > 4) Security of runtime / tool chain: It should be hard to
> > inconspicuously backdoor the tool chain and, if applicable,
> > runtime environments.
> >
> > To give two concrete examples:
> >
> > Using the C language + deterministic builds is an attractive option
> > with respect to 1), 2) and 4), but doesn’t provide much regarding
> > 3).
> >
> > Java does better with respect to 3), however, it trades some of 3)
> > and 4) as compared to C. Specifically, we are concerned that large
> > runtimes may be difficult to audit. A similar argument may apply to
> > other interpreted languages.
> >
> > Given these criteria, what language would you choose and for what
> > reasons? We would also appreciate feedback regarding our criteria.
> >
> > All the best, David, Nick, Peter, Stevens, and William
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBCAAGBQJTVp7DAAoJEBEET9GfxSfMQMAIAL/P3WfYgLeNe9oa5SQhtTEO
> JXdP41q7UNS1ZznRMY+gsKLNZr3bjaSfJiLqALVkNl8XpHQCAbMwFowxtmkcvah/
> 7ZwXhT2Y2OT3DwobnT/173T611I3+w6QG4AJULmVt02mU01XeUuN23UPVYNjOZ/M
> ZQrbZ6E45kes7Qq2TAG8FwK4tTnmjzzEyr9W0VOH/x9j1+oes4t2BHAM8cpb7+cr
> E0aJLAJCth0ICt0nK2Ms6R1T7NyrgdzQLI+YJ3PGiyz5ajxyEfohrvfPkfPPeAEW
> nmLly6GSga/gmQzx7yLNgUj7h4tD1IMkC5CTWu4Yd1kd2LLF8kEto03rPf6+Au0=
> =GMPw
> -----END PGP SIGNATURE-----
> --
> 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
> companys at stanford.edu.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140422/352f887b/attachment.html>