[cap-talk] Language-based safety - notes and meat)
markm at cs.jhu.edu
Sun Nov 14 13:42:07 EST 2004
Hal Finney wrote:
> I lurk on the e-lang list, and it seems that Kevin Reid finds bugs in
> E pretty regularly.
Yes, Kevin is doing an extraordinary job of finding bugs in E. I just can't
praise his efforts enough. Much of my confidence in E's current state and its
ongoing evolution is due to his efforts.
> They are usually extremely technical and I have
> little understanding of what they mean. Are any of these security bugs?
> Or are they all pretty much just flaws in functionality that don't affect
> the security guarantees?
Several have been security bugs. At least one was huge enough to drive a truck
It was a complete surprise and took us a long time to close.
> I'm trying to get an understanding of how secure you think E is right
> now given the inevitability of bugs in a program of the complexity of E.
I think the best guide for answering this starts by looking at our bug
database -- the frequency over time, the severity, etc... Regarding the bugs
we classified as security bugs, earlier I wrote:
The known-open security bugs in any of [E, CapDesk, DarpaBroswer] can be found at
The thought-closed security bugs can be found at
Although you should also scan the other bugs to see if we misclassified any.
If you see any, please let me know. If you know of bugs that aren't captured
in this database, please let me know.
I expect this past to be a fairly good predictor of the future, but there's
always the possibility of an even nastier surprise lurking. I leave it to each
of you to judge how much confidence you can have in E-on-Java given this
history. But I make no apologies. To my mind, this kind of history is how one
incrementally improves real systems under use. I expect E-on-Squeak to follow
a similar process. It'll be better in some ways because it'll be simpler and
cleaner, it'll be building to a language spec that is now mostly settled, and
it can learn from E-on-Java's mistakes. But until it matures, it'll also start
with a high incidence of new mistakes.
If the past is indeed a good indicator, I expect most of our remaining
security holes are taming bugs, and most of these are in taming the guis.
Given this, perhaps the most important outstanding bug to fix is
as that'll take the gui taming out of the attack surface for some uses.
However, it won't affect the attack surface CapDesk presents to the caplet
writer, as caplets are given access to the tamed gui regardless.
Text by me above is hereby placed in the public domain
More information about the cap-talk