[Cryptography] GnuTLS -- time to look at the diff.

Ben Laurie ben at links.org
Fri Mar 7 04:38:22 EST 2014

On 7 March 2014 06:55, Watson Ladd <watsonbladd at gmail.com> wrote:
> 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.

What is the Power of Ten?

> But because C forces manual
> memory management cleanup gotos have become accepted style.
> Correctness simply wasn't a priority.
> Sincerely,
> Watson Ladd
> --
> "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 mailing list