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

[ianG]

On 4/03/2014 01:07 am, Sampo Syreeni wrote:

> So my point is, while you probably can guard against certain errors via
> syntactic means like forbidding gotos, you really, *really* can't guard
> against all of them, and even if your failure model is a
> bored-to-silliness coder repeating something via a careless paste
> operation, you're in general probably out of luck.
> 
> Second, as for gotos per se, I believe they're a misunderstood beast.
> Most who rail against them never read or at least understood Dijkstra's
> original demurral. His point wasn't that goto's are bad per se. It was
> that they invite the kind of undisciplined coding style and muddled, ad
> hoc thinking style about algorithms which leads to spaghetti, and soon
> thereafter to code you can't (provably) formally analyse or verify.


Right, now have a read of the code in question.  You will see it wasn't
just the inadvertent C&P that was the problem.  What was at deeper issue
was the error handling flow, which was structured around a goto concept.
 There were several flaws present, one of which was that there was a
default good condition, another of which was that the branch-by-goto did
not carry the error with it.


> So, gotos don't automatically lead to trouble, nor are they evil an
> sich. With proper, slavishly elegant, high coding style they can
> actually serve you pretty well on occasion. It's just that they make it
> so very easy to hose yourself, and as such, it'd be better to leave them
> out of language syntax.


Exactly.  Follow that thought when reading the code...  The use of the
goto in this case was expressly bad because it created/caused/led to an
unreliable error handling flow.

The calls to replace the gotos are simple ones.  They are for simple
programmers who don't understand why they are dangerous.  Best to use
simple rules there.

The underlying call is to refactor the code *to handle errors*.
Security code and reliability code (same thing really) is all about
errors.  If you aren't programming for errors, you're not doing security
coding.


> In this case, there was nothing wrong with the coding style per se. What
> probably happened was an inadvertent double paste which wasn't caught in
> time. As I argued above, that's not a problem which is intrinsically
> tied to gotos, and quite probably (absent some work in formal grammars
> I'm not aware of) something not something you can fully and/or usefully
> control via syntactic means. Instead it seems like a problem for quality
> assurance.


No, it's a problem for coding style.  Quality assurance cannot improve
on a bad style;  QA can make it less errorful, and so can testing, but
neither can make it less error-prone.


> Also, let's see the performance numbers. As much as we'd like to see
> omnipotent compilers doing miraculous global transformations to program
> flow, especially in C-like low level languages neither the necessary
> semantics for the compiler to do its theoretical maximum, nor the
> willingness of the compiler developer to even try such program
> transformations, just aren't there. Thus, if the programmer is forced to
> do it via nested ifs, the result is often not as fast.


Sorry.  Security code.  SHAs, pk sigs.  Forget performance.


> Yeah, I know a development framework or two myself. But I don't think
> any real consensus exists about what you should really do, and in what
> priority order, in order to get various levels of assurance. Especially
> when indexed by economic viability, instead of abstract, ad hoc,
> theoretical niceness/beauty standards.


Right.  The problem is that the sort of tests that are espoused -- the
negative is negative tests -- are expensive to write.  And they deliver
no obvious or tangible benefit because ... the code already works,
right?  Once people are on deadlines or bug queues, and managers are
grumpy, doing what is 'right' as opposed to what you can get away with
is hard.

It's a thing, it's not a happy thing, but reality is what it is.

Until we can measure and tangibalize (!?) the cost of an apple goto fail
or a debian random delete, we cannot expect it to play much part in the
process.  In essence, we all accept the risk.  We all walk in the shadow
of Papa Legba, the god of bugs.



iang