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