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

[Watson Ladd]

On Fri, Mar 7, 2014 at 2:23 AM, ianG <iang at iang.org> wrote:
<sniped>
> 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?

http://spinroot.com/p10/

The JPL coding style is a more expanded view. In particular, hashing
should never fail: it's computing a function, therefore doesn't need
to allocate any resources. Letting it return failure breaks several
rules in the JPL coding style, in particular the preference for total
functions. The apple bug resulted from handling errors that should never happen.

The gnu TLS verify.c code uses nonstandard control flow. Had the goto
cleanup been written as cleanup, followed by return, it would be clear
that the wrong value was being returned. Several times a comment is
made that a function returns only 0 or 1. If that's the case, write
the function to return only 0 or 1 or make assertions to force that. A
single assertion before return ensuring the returned value was in
scope would have turned this into a bug, instead of an exploitable
issue.

So applying a "set of best practices" clearly didn't work, while
turning comments into assertions where possible, using simple flow
control, and validating inputs and outputs of functions would have
prevented both of these issues.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin