Re: [GNUnet-developers] Why old-school C?

[Andrew Cann]

Fair call, most of those problems can't be tackled with better programming
languages (I wasn't refering to rust in particular btw). But some of them can
be.

  * scalability/performance
    What if you could guarantee that your service will process any message of n
    bytes in O(n log(n)) time and memory. Or that a network of n available
    peers connected in such-and-such a topology can route any message in less
    than m hops. There are programming languages that could let you express
    these kinds of constraints and check them at compile time.

  * Compiler/VM might be buggy. See Java.
    Java doesn't offer the kinds of static correctness guarantees that I'm
    talking about. Nor does C, which Oracle's JVM is written in. Languages with
    advanced type systems are basically theorem provers where the code is a
    proof of it's own correctness. If you write a program in a language like
    that, and you write the compiler in the same language, then you have a
    program that has been proven correct with a static analyzer which has also
    been proven correct by itself. At that point it's pretty unlikely that your
    program is buggy. Trivially, the compiler could just accept any program as
    correct but people would notice that bug pretty quickly. It would be much
    harder to slip through a bug that causes the compiler to seem to work most
    the time but causes it to not notice it's own bug. The stars would have to
    align, so to speak.
    
  * side channel attacks
    Some things, like the number of CPU cycles it takes to execute this
    decrypt() function, could in principle be modeled inside a programming
    language. I don't know if any of the dependently typed assembly languages
    let you do this.

  * disclosure via protcols, meta data leakage
    I'm not sure exactly what you have in mind, but if you want to prevent
    leakage there are type theories that let you enforce things like "the value
    in this variable at time t can not effect the output of this function at
    any future time". 

The language that does all these things doesn't exist yet. So sorry if I'm
derailing the discussion with my hypotheticals. However I wouldn't describe the
security problems that rust solves minor either. Looking at the results of the
this year's Pwn2Own 
(http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Pwn2Own-2015-Day-Two-results/ba-p/6722884#.VZ6B00QvCCg)
The bugs exploited by the top prize winners were:
  * "an out-of-bounds read/write vulnerability" - solved by rust
  * "time-of-check to time-of-use (TOCTOU) vulnerability"
  * "privileged JavaScript injection"
  * "a buffer overflow race condition" - solved by rust (probably)
  * "an info leak"
  * "a race condition in [a] Window's kernel driver" - solved by rust (probably)
  * "use-after-free (UAF) vulnerability" - solved by rust

4 out of 7 aint bad. This is, after all, why Mozilla decided to work on Rust -
because they were sick of dealing with security vulnerabilities in firefox.

 - Andrew

signature.asc
Description: Digital signature