[Cryptography] GnuTLS -- time to look at the diff.
watsonbladd at gmail.com
Fri Mar 7 01:55:19 EST 2014
On Thu, Mar 6, 2014 at 8:20 PM, Ben Laurie <ben at links.org> wrote:
> On 7 March 2014 01:21, Watson Ladd <watsonbladd at gmail.com> wrote:
>> On Thu, Mar 6, 2014 at 3:46 PM, Salz, Rich <rsalz at akamai.com> wrote:
>>>> 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.
>>> 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.
>> And if you want to get it right, why use C? A bug in your C code could
>> look at places it shouldn't, and thus break the whole thing apart.
>> There is no reason today to not use memory-safe languages
> Of course there is: integration with existing code.
>> or isolate
>> crypto code from code that can break its security.
> How would that have helped with either the Apple SSL or the GNUtls bugs?
There is no reason why either function needed manual resource control.
The absence of memory safety and nonexistence of a genuine bool type
made both functions impossible to understand. Staying in C, applying
the Power of Ten would have worked fine. But because C forces manual
memory management cleanup gotos have become accepted style.
Correctness simply wasn't a priority.
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
More information about the cryptography