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

[Theodore Ts'o]

On Mon, Mar 03, 2014 at 11:00:36AM +0000, ianG wrote:
> 
> Second, it's a huge gap between knowing what to do, and doing it.

Those who can't do, teach.  :-)

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

If open source maintainers accepted every single patch that the
senders were convinced were great ideas, I assure the code would be
far buggier, and far less secure.  Trust me, I've seen the bright
ideas and (to their minds) brilliant patches people send; the vast
majority of them are terrible, and the one of the big reasons why
Linux's random driver and ext4 code is better is because I reject (or
ignore) the vast majority of crappy patches.

But hey, if you can convince everyone else to follow your rewrite of a
project, then it is open.  The problem is that most people aren't
willing to trust random people who claim that they can improve code,
or worse, they aren't willing to stand behind the code base, and send
"drive by patches" and aren't willing maintain the code over the long
term.  So the fact that most attempted code forks never gain traction
is a not surprising --- and, and I claim, it's a good thing.

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

And Peter Gutman's magic 30 pass secure HDD rewrite is still
applicable today.  Seriously, the work done in the 1970's and 1980's
is not necessarily valid for today's coding styles.  More importantly,
it's not enough to do work just saying that <FOO> is bad.  All coding
techniques have downsides.  This is why I said that the only way that
you're not doing speculation or argument by assertion is to take a
look at the number of bugs (security and otherwise) with alternate
techniques, since it may be that an alternate technique avoids one
class of bugs, but ends up opening the code to other classes of bugs.

It certainly wouldn't be the first time that conventional wisdom on
things like "Microkernels is the only way to write Operating Systems"
would turn out to be disastrously, terribly, wrong.  Sometimes when
academic theorizing runs into the concrete wall of actual pratice,
theory doesn't necessarily survive the impact with actual engineering
reality terribly well.

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

Nope, it just requires someone to start writing code, and
demonstrating to others that their code base is better.  Not just in
theory, but in actual fact.  The IETF mantra of "rough consensus and
running code" is really important here.  Especially the last bit of
"running code".

So this is the big difference the two links you pointed out.  Your
second one:

> https://www.mail-archive.com/cryptography@metzdowd.com/msg12958.html

Was basically saying, Someone Else should do something!

> Brave steps:  here's a relative newcomer to the scene:
> https://en.wikipedia.org/wiki/QUIC

And this is running code (both client and server), released under open
source, and there are even servers on the web which are usign this new
protocol.

See the difference?

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

"You can't change people; you can only change yourself".

What's *your* strategy for making *your* life easier?  And if it so
happens that your strategy can also make the rest of our lives easier,
and you are willing to contribute some effort to make that happen,
even better.

One of the things which demotivates volunteers (and open source
projects are fundamentally very much like any other volunteer
effort), is other people telling them that their work suck, and
other people demanding that they be able to dictate how they spend
their volunteer time.

So if you tell me how I should spend my time, I'll tell you to f*ck
off.  If you send me small, easily reviewable patches, each one which
improves the code base, I'm much more likely to respond positively, or
at least tell you why in my opinion, it might not be considered an
improvement, and whether the patch can be changed so that it would be
acceptable.  (But note that I'm not going to demand that you change
the patch; only that this is the work that would be needed before I am
willing to accept the patch; the difference is subtle, but important.)

Cheers,

						- Ted