holes and vulnerabilities

Bill Frantz frantz@communities.com
Mon, 21 Dec 1998 18:49:08 -0800

At 05:19 PM 12/21/98 -0800, Norman Hardy wrote:
>Perhaps holes are dispensible (but see
><http://www.mediacity.com/~norm/CapTheory/Retrieve.html>); I think,
>however, that real durable objects must suffer a variety of vulnerabilities
>in practical situations. I really want to know if I can live with out some
>six year old 15 megabyte library, or must I continue to pay for this
>proprietary Runge-Kutta service.

[#]The idea of durable objects always bring up the question, how durable?
When we turn a computer off for the last time, we ask, what is on it that
we will need.  It seems in all cases, you want to be able to play what if I
no longer had this object.  There seem to be three ways of dealing with
this problem:

(1) Caveat Programmer, as in C.  Nothing happens to pointers to deleted
objects.  Features: Low overhead, obscure bugs, security exposures.

(2) Garbage Collection, as in Lisp/Smalltalk/Java.  Now the question
becomes, why isn't this object being deleted and how long do I have to keep
paying to store it.  Features: Relatively high maintenance overhead, not
knowing why you are keeping an object.

(3) Zap, as in KeyKOS, where deleted pointers have well defined semantics.
Now the question becomes, when I zap something what am I going to break.
Features: Relatively high pointer following overhead, not knowing what will
break when I zap something.

In case 2, we can build tools that act below the level of abstraction of
the objects which will tell us why an object is being kept.  It may even be
possible to automatically identify "interesting" objects, e.g. those
objects with few in-pointers which pin a lot of space.

In case 3, we might be able to build tools which would identify all the
objects which hold pointers to an interesting object.  The tool set may be
quite similar to the case 2 tool set.

In either case, the tools operate below the level of abstraction of the