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

[ianG]

On 7/03/2014 06:55 am, Watson Ladd 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.


Other than being stuck in C, sure.  Well, even there, there are several
strategies for dealing with it:  pass the variables in to the function
and have the caller handle it.  Do it on the stack, do it in statics,
that's what functions are for, etc.  They weren't doing it.

Why not?  I'd bet it is a combination of fear of bugs, lack of resource,
lack of testing, momentum of the codebase.


> The absence of memory safety and nonexistence of a genuine bool type
> made both functions impossible to understand.


I agree with the former, C not having memory control makes it very
expensive to write in.  My informal experiments lead me to believe it is
5 times as costly to write in than an OO language.  So yeah, I'm tired
of those weeds too.

However, the bool issue is a siren, it's much messier.  What occurred in
both those examples was inadequate treatment of the error conditions,
and it manifested itself in several ways:

  * overloading bools with error codes
  * using manifest numbers instead of declared constants
  * overloading of variable usage
  * conversion of error status on the fly
  * transmission of error status along the flow of code

It really is all about the errors.  And the answer to this is style ---
establishing a set of practices that best works with the language you
are stuck with, and best allows the flow of errors.


> Staying in C, applying
> the Power of Ten would have worked fine.


OK, I byte!  What's the power of ten?

> But because C forces manual
> memory management cleanup gotos have become accepted style.


They aren't globally acceptable.  They are locally acceptable in those
two TLS source bases, manifestly.  But Peter posts that he doesn't in
effect accept them as style in his C implementation, and his gnashing at
defeat in one single case proves the point.  So it isn't even acceptable
universally within the SSL community.

What I find curious is the almost mirrored style from OpenSSL to gnuTLS.
 It's as if the latter just copied it all just to get a licence change.
 Idle speculation, but the cultural impact is something to consider here.


> Correctness simply wasn't a priority.


Hmm.  Tipping at Nico's complexity argument, I'd say that correctness is
a possibly unachievable target.  I'd prefer to prioritise safety.  Err
on the side of...  Because, I never got the impression from PKI that
there was one precise correct answer to every case.  That's just me,
those that have sold their life into it might say different.

unfortunately I suspect those who are in there and writing the code
probably prioritise to speed & efficiency.  It's the only reason I can
think of to use those goto layouts.



iang