Search Mailing List Archives
[liberationtech] Programming language for anonymity network
lindener.peter at gmail.com
Tue Apr 22 10:26:08 PDT 2014
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
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
> 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.
> 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)
> -----END PGP SIGNATURE-----
> Liberationtech is public & archives are searchable on Google. Violations
> of list guidelines will get you moderated:
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the liberationtech