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

[Ben Laurie]

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