[pro] Heartbleed?

[Alexander Schreiber]

On Tue, Apr 29, 2014 at 12:40:09AM +0200, Pascal J. Bourguignon wrote:
> William Lederer <william.lederer at gmail.com> writes:
> 
> > Regarding the question
> >
> > What would you personally fly, software written in C or software
> > written in Common Lisp? 
> >
> > In the reality of today's fly-by-wire, the modern planes you fly in
> > are likely to have C in some critical component. Ada is likely there
> > as well.
> >
> > But let's just examine a few software related disasters to see if
> > they are attributable to programming language:
> >
> >     Ariane 5 rocket explosion: from the official report: This loss of
> >     information was due to specification and design errors in the
> >     software of the inertial reference system.
> >     Mars Climate Orbiter: one system used metric units, another used
> >     English
> >     Therac 5: improper understanding of multi-tasking code
> >     Heartbleed: Overly complex protocol combined with being able to
> >     read beyond allocated memory
> >
> > Of these, only heartbleed can credit language as a contributing
> > factor.
> 
> Not at all.

Any programming language will have a hard time protecting you from
design/specification errors. And providing bandaids that paper over
design problems doesn't really help.

>   * Programmed in Common Lisp, either the fixnum in the Ariane 5 would have
>     been converted into a bignum, or an condition would have been
>     signaled, which could have been handled.  This would have taken
>     time, which could perhaps have "exploded" the real time constraints,
>     but it is better to control your rocket slughishly than not to
>     control it at all.

That was not the real problem. The root cause was the design assumption that
overflowing value was _physically_ limited, i.e. during normal operation
it would have been impossible to overflow and an overflow would in fact have
signaled some serious problems bad enough to abort. While this held true in
Ariane 4, it no longer was true in the more powerful Ariane 5.

Your "solution" would have papered over the flawed design assumptions, which
is _not_ the same is fixing them.


>   * Programmed in Common Lisp, instead of using raw numbers of physical
>     magnitudes, you'd use objects such as: 
> 
>       (+ #<kilometer/hour 5.42>  #<foot/fortnight 12857953.0> )
>       --> #<meter/second 4.7455556>
> 
>     and Mars Climate Orbiter wouldn't have crashed.

This is ridiculous. If you end up mixing measurement systems (such as metric
and imperial) in the same project, you are _already_ doing it horribly wrong.
The design fault was mixing measurement systems, which one should _never_ do
on pain of embarassing failure. Papering over this design screwup with a
language environment that _supports_ this (instead of screaming bloody
murder at such nonsense) doesn't really help here.


>   * Programmed in Common Lisp, the Therac-5 bug wouldn't have occured:
> 
>       "The defect was as follows: a one-byte counter in a testing
>        routine frequently overflowed; if an operator provided manual
>        input to the machine at the precise moment that this counter
>        overflowed, the interlock would fail."

But why did the counter overflow in the first place? Was it simply programmer
oversight that too small a datatype was used or was this actually an error
that just didn't have noticeable consequences most of the times?  If the
later, then again, papering over it with a never overflowing counter is
not a fix.

>     since again, incrementing a counter doesn't fucking overflow in
>     lisp!
> 
>   * Programmed in Common Lisp, heartbleed wouldn't have occured, because
>     lisp implementors provide array bound checks, and lisp programmers
>     are conscious enough to run always with (safety 3), as previously
>     discussed in this thread.

Hehe, "conscious enough to run always with (safety 3)". Riiiiight. And nobody
was ever tempted to trade a little runtime safety for speed, correct?

As for heartbleed: arguably, the RFC that the broken code implemented
shouldn't have existed in the first place.

> What I'm saying is that there's a mind set out-there, of using modular
> arithmetic to approximate arithmetic blindly.  Until you will be able to
> pay $1.29 for 3 kg of apples @ $2.99, people should not program with
> modular arithmetic!

Well, modular arithmetic doesn't go away because one wishes it so. As a
developer doing non time critical high level work one might be able to
cheerfully ignore it, but the moment one writes sufficiently time critical
or low level code one will have to deal with it. Because modular arithmetic
is what your CPU is doing - unless you happen to have a CPU at hand that
does bignums natively at the register level? No? Funny that.

> > And I again point out a software non-disaster qmail, whose author
> > offered a bug bounty. Secure programs can be written in C.
> 
> postfix too is architectured to deal with security.
> 
> You can also write secure software on a Turing Machine.

Software running on _actual_ Turing machines tends to be of mostly limited
use, though.

> > And if the flight safety of an aircraft depended upon the current
> > Lisp version of Ironclad's impenetrability, we would be in trouble.
> 
> This is another question, that of the resources invested in a software
> ecosystem, and that of programming language mind share.   Why the
> cryptographists don't write their libraries in Common Lisp and choose to
> produce piles of C instead?

Usefulness. If I write a library in C, pretty much everything that runs on
Unix can link to it (if need be, via FFI and friends) and use it. If I write
a library i Common Lisp, then code written in Common Lisp can use it unless
people are willing to do some interesting contortions (such wrapping it in
an RPC server).

Exercise for the interested: write a library in Common Lisp that does, say,
some random data frobnication and try to use it from: C, Python, Perl, C++
_without_ writing new interface infrastructure.

Kind regards,
             Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison