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

[Chas.]

You could also try using some of the great tools out there to reduce the
security risks. Look at Veracode for their Analysis Center. There are some
open source tools you can use as well.

C.


On Tue, Apr 22, 2014 at 12:54 PM, 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-----
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at lists.zooko.com
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140422/ee146cdb/attachment.html>