[cap-talk] Language-based safety - notes and meat)

[Mark Miller]

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 
through.
<https://bugs.sieve.net/bugs/?func=detailbug&bug_id=125579&group_id=16380>
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
<http://bugs.sieve.net/bugs/index.php?group_id=16380&set=custom&_assigned_to=0&_status=1&_category=100&_bug_group=2803&SUBMIT=Browse>
The thought-closed security bugs can be found at
<http://bugs.sieve.net/bugs/index.php?group_id=16380&set=custom&_assigned_to=0&_status=3&_category=100&_bug_group=2803&SUBMIT=Browse>

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
<https://bugs.sieve.net/bugs/?func=detailbug&bug_id=125636&group_id=16380>
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

     Cheers,
     --MarkM