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

[ianG]

On 3/03/2014 01:50 am, Theodore Ts'o wrote:
> 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.


Just in order to clear up any confusion, I'm not begging it, I'm stating
it.  *Bad coding style*.  IMHO, a goto cleanup handler is an atrocious
thing.

Just so there's no mistake here...


> 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.


Let's not confuse 'what people do' with 'good/bad coding style'.  Also,
just because Theo has a rep as a security devil doesn't necessarily mean
his patch is the cleanest.

As far as I know, OpenSSH adopted OpenSSL or parts thereof.  I would not
have advised them to do that, because they would inevitably end up with
things like 'bad coding styles'.  Indeed, I would have advised (and do
advise) them and everyone to do everything exactly different, as a fair
chance at accidentally improving matters.

But hey, they are adults.


> 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.


As to the yaddayadda about it being open source and everyone's welcome
to give it a go, no, sorry, might be the geek fantasy but it isn't the
reality.  Firstly, the open code is closed.  You can't just wander in
and fix it, they've got repos, barriers, code reviews, reputation, etc
to get through.  It's about as likely as me sending a dev/random fix in
to linus and expecting it to be slotted in.

Second, it's a huge gap between knowing what to do, and doing it.
Programmers have to eat.  And this particular programmer has already got
his extensively huge project.

The reality is that as an open source project, we get to criticise it
from the armchairs, and Openssl/ssh will ignore us totally.
Occasionally a real blooper like this might slip through and they might
respond, but let's not hold our breath on that one.  But for the most
part, open source projects are effectively closed, we have more
influence over the practices of commercial closed-source projects
because we can embarrass them in the media.


> 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.


Thanks but no thanks.  Recall an influential letter to ACM?  To be
frank, I'm not that keen to go back to the dregs of the literature of
the 1970s or 1980s when this work was likely done, in droves.  So I'll
pass on the academic shut-down.


>> 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.


I would actually agree with that.  Whole-heartedly.  We need to start
again.  Big time, not fiddling around at the edges.

Now we are left with:  why hasn't this been done?  I've indicated some
reasons above, another reasons is shear inertia.  A fourth reason is
hubris, 99% of the people involved think that they are doing a good job
(and they might be right) and therefore criticism is wrong and should be
dismissed out of hand (right or wrong, no change needed here...).

If there is going to be any rewrite of this, it actually needs to start
by first getting the consensus moving that OpenSSL in particular and SSL
in general is utter crap.

Once the mental barrier is torn down, people might then take the brave
step of building a replacement.

Brave steps:  here's a relative newcomer to the scene:
https://en.wikipedia.org/wiki/QUIC
There are others.  DJB has a paper somewhere that is poorly linked and I
can never find it.  Here's my idea on the group:
https://www.mail-archive.com/cryptography@metzdowd.com/msg12958.html


> 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....)


Yup.  However, the fact that this is a difficult task needs to be
separated from the fact that they are running with a code base that
makes their job and our lives harder, and they have no strategy for
improvement.


> 							- Ted
> 



iang