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

Bear bear at sonic.net
Mon Mar 3 14:04:49 EST 2014

On Fri, 2014-02-28 at 17:03 -0800, Dennis E. Hamilton wrote:

> A pretty-printer (or any IDE that reflows indentation) would point it out.  
> So would a modern IDE that identifies unreachable code.  
> Any practical code-coverage testing would reveal it too.

Okay, I have to say this despite the complaints on this 
list about how common TERRIBLE security practices may be.

This is completely over the top.  There is no way that this
could possibly be accidental.

In point of fact, I know of no commonly used or commercially 
sold compiler that fails to emit unreachable-code warnings 
by default.  Therefore I do not believe that this could be 
anything but deliberate.  I would be willing to state exactly 
that in a court of law.

It is unthinkable that ordinary process in a professional 
software shop should silence all code warnings.  Routines 
for which a normal code warning should be silenced, for a 
particular known reason, should be placed in files containing 
no other routines and subject to silencing of no other 
warning, with a comment next to the line that triggers the 
warning stating exactly why this code had to be written this 
way and why it is better to silence the warning than fix the 
code.  Alternatively, if the compiler supports inline pragmas
that turn off particular warnings for given regions of code, 
it's acceptable to pragma that single line, with the same 
comment about why the pragma has to exist. 

That isn't even special security practice, or special for 
security code, that is absolutely routine for all software 
in every shop I've ever worked at.

Make no mistake, this was not an oversight.  This was a 
deliberate sabotage.  If working as a manager, I would 
want to know not only who checked in the code with the 
change, but also who checked in the build control changes 
that had to be added to silence the warning.  The code 
change itself merits termination for negligence, incompetence, 
or sabotage. If whomever checked in the build file changes 
did so at a time when that was not a (mal)practice already 
years established, or other than under direct orders from 
a(n incompetent) manager, that would also merit termination 
for deliberately violating basic professional practices.

It may or possibly may not be enough evidence for a court 
conviction, but it certainly is enough for probable cause 
and a trial, and certainly justifies a termination for 
incompetence or negligent practice.


PS.  Any language that allows "goto" without use of a 
keyword that can be searched for project-wide without 
knowing the label gone-to is at best suspect.  It should 
be terrifyingly easy (as easy as "grep -r goto *") to 
find all uses of a Dubious Practice.

More information about the cryptography mailing list