ECMAScript ("Javascript") Version 4 - FALSE ALARM

[D. Hugh Redelmeier]

| From: Ian Petersen <ispeters-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>

| Walter, I don't know your background, so sorry if you already know
| this, but once a language reaches Turing completeness, the only way to
| make it "more powerful" is to make it aesthetically better in some
| dimension.

That is true in theory.

That same kind of theory say FALSE implies anything.  In other words,
once you have a contradiction in a system, nothing can be known about
it.

The real world is different.  Security is an estimated
probability distribution function, not a binary value.  Lots of things
can affect this PDF.

The major enemy of competent folks engineering a secure system is
complexity.  Well, complexity and management :-) :-)


Anecdote:

In the mid 1970's I went to a talk at the U of T by an eminent computer
scientist.  His talk was about building a secure subsystem on an
insecure platform.  In particular, a student PL/I compiler (PL/C) on
top of OS/370.  It the talk I asked: how could he be convinced that
he'd achieved security when the interface to be secure was so broad
(PL/I was considered a very big language at the time).  He said that
he was sure.

It took me 15 minutes to crack PL/C (remember: this included punching
cards and waiting in line to submit the test runs).  And I'd not tried
to crack it before.  It took the interaction of three features:

- multi-dimensional arrays (I chose 256 * 256 * 256 * 256 to cause an
  overflow in the size calculation)

- run-time dimensioning (because compile-time overflow was detected)

- PL/I's exception handling (to suppress the run-time overflow check)

See how complexity was my friend?

His theory was sound but the engineering was difficult because of
complexity.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists