<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 6, 2014 at 3:46 PM, Salz, Rich <span dir="ltr"><<a href="mailto:rsalz@akamai.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=rsalz@akamai.com&cc=&bcc=&su=&body=','_blank');return false;">rsalz@akamai.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Buffer overruns are a very clear example. We could use languages, PL/I is one of the early ones, where buffer overruns are not possible, but we don't.<br>


<br>
</div>I don't know about you, but I would rather have an SSL/TLS library that I can call from my C, and other, code that has some bugs. Then have a bugfree implementation written in some language that I cannot use.</blockquote>

<div><br></div><div>This is not only some of the worst security advice I've ever heard, but a painful false dichotomy.</div><div><br></div><div>There are memory safe languages that interoperate just fine with C, like Rust, which would eliminate the entire class of errors we've seen behind the recent TLS stack breakage. Beyond Rust's memory safety, it does things like mandate braces around if statements (which would've prevented "goto fail"), and has proper boolean types natively as well as an Option type which would eliminate the sort of confusion around return values which lead to the GnuTLS (a bad pattern seen in <a href="https://www.openssl.org/docs/ssl/SSL_shutdown.html">OpenSSL as well</a>).</div>

<div><br></div><div>Last but not least, Rust knows how to automatically deallocate memory and call destructors, so it doesn't have or need a goto statement for this sort of stuff.</div></div><div><br></div><div>TLS is worthless unless we have the closest thing to a bug-free library possible. C is not getting us there.</div>

<div><br></div>-- <br>Tony Arcieri<br>
</div></div>