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

[Jerry Leichter]

On Mar 9, 2014, at 12:40 AM, Watson Ladd <watsonbladd at gmail.com> wrote:
>> 
>> OK, I byte!  What's the power of ten?
> 
> http://spinroot.com/p10/
> 
> The JPL coding style is a more expanded view.
Interesting.  Some of the ideas are good in general; others are highly specific to C.  I'm a bit disturbed, given that they are specific to C, to find that:  "The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed."

Ahem:  No version of the C preprocessor has ever supported recursive macros!  (There are other 

It's also disturbing to see the section on checking error returns give as example functions printf() and strcat() - two functions that are inherently extremely difficult to use in a safe way, and which by 2006 when the paper was written had alternatives that provided explicit lengths that were much safer.

They recommend assertions that turn into no-ops at run-time, resulting in the rather bizzare-looking recommended form:

	if (!c_assert(p >= 0) == true) {
		return ERROR;
	} 

which in essence punts the problem to the caller.  The Ariane 5 failure http://www.ima.umn.edu/~arnold/disasters/ariane.html shows what happens when errors are checked but doing something about them is considered Someone Else's Problem.

> 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.
I pointed this out earlier - but it's a bit more complicated than that.  The functions pass around a state object, and it's a common design pattern in careful C code - I don't know whether it's followed here - to mark such objects with an indication of what kind of object they are.  For one thing, if the state objects for, say, different hashes are of different sizes, this provides some assurance that the state object passed in is actually large enough that the function can safely write into it!  In that case, a checked error may prevent a memory overwrite.  By choosing a different reasonably large tag value for each type you use, you can even have some chance of detecting heap memory overwrites.  (You can think of this as manually adding dynamic type checking to C.  The technique is almost never used in C++ because *well-written* C++ can be statically type checked.)
                                                        -- Jerry