[Cryptography] The GOTO Squirrel! [was GOTO Considered Harmful]

[Theodore Ts'o]

On Sat, Mar 01, 2014 at 03:55:55PM +0000, ianG wrote:
> 
> Au contraire!  You've fallen to exactly the same trap that you accuse
> others.  You see that we are all focussed on cause A: bad code, and we
> are missing cause B: lack of process.  By saying it is all about B, you
> are missing that A is a contributor.

You're begging the question about whether the "goto cleanup handler"
coding style is a bad coding style.  Yes, it was present for this
particular failure, but so was the fact that the author was right (or
left) handed.  Does that mean being right handed was a contributor?

I'll also note that Openssh uses the "goto cleanup handler" coding
style, and most people I think would consider Openssh to be (a)
cleaner code, and (b) less likely to contain security bugs than
OpenSSL.  If you plan to completely refactor openssh to use some other
coding style --- let me know.  I want to be in the bleacher seats,
eating popcorn, while watching Theo respond to your bright idea.

If someone would like to gather some hard data about whether
hopelessly deeply nested if statements is less or more error-prone
than using the "goto cleanup handler" style, that would be great.  But
until that work is done, what I see is a lot of assertions and assumptions.

> Or, in other words, as suspected by a consensus of programmers here
> who've lost their dinner, a massive refactoring exercise is *the good
> engineering and delivery process that was missing in OpenSSL*.
> 
> (This is not a new observation, I first saw admission that OpenSSL is a
> dog's breakfast at least 15 years ago.)

There are plenty of things wrong with OpenSSL besides the use of goto.
For one thing, its API design is execretable, such that pretty much
any functional change is almost guaranteed to break ABI compatibility,
which gets quite painful if you are trying to use shared libaries.
Also, if you want to make the code to be more easily testable using
unit tests, this has to be taken account when you are designing the
API.

So I'd argue that it wouldn't be a good use of programming effort to
refactor OpenSSL.  Probably better to take off, nuke it from orbit,
start from scratch, and design the API from the beginning to be easily
extensible and testable, and most importantly, write the tests while
you are reimplementing the code, from the ground up.

Testing is like security.  You can't just sprinkle the magic testing
pixie dust after you are done implementing, just as you can't (at
least not practically) try to add security after the fact, if it
wasn't designed in from the beginning.  (Or if you can, it requires
infinite budgets....)

							- Ted