Re: Idle musings on doing E over again

On 10/1/12 at 7:44, [email protected] (Kevin Reid) wrote:

>>1. VatTP not using standard TLS libraries -> security risk due to lack of
>>updates.
>
>As far as I know, The Plan Always Has Been to move to standard 
>SSL/TLS/whichever-it-is-HTTPS-uses plus key checking; it's just 
>that nobody has gotten around to implementing this in all these 
>years. Certainly a new from-scratch implementation would take 
>advantage of the latest libraries.

I spent a considerable amount of time on this issue 12 or so 
years ago. Note that SSL and TLS are the same thing, TLS is a 
more modern version of SSL. HTTPS will use either, but there are 
significant security issues with SSL1 and SSL2, so modern 
browsers only will support SSL3, which also has issues, but they 
are less likely to show up in real-world situations.

In the good old days, TLS was totally in bed with PKI and 
certificate authorities. There are some recent RFCs which allow 
the kind of key authentication needed for E, i.e. the public 
key's hash is the vatID of the target vat.

I found the whole library thing a total none-starter. What TLS 
libraries will be supported over all the target platforms? What 
libraries provide the necessary interfaces to check the public 
key against the vatID? I'm probably really old fashioned, but 
coding the crypto from scratch seems a lot easier than answering 
the above questions and validating the security of a library.

(The problem with security is that is isn't what you can do, 
which can be answered by testing, but what you can't do, which 
can only be answered by proof, although tiger teams can give you 
some hints.)


>>5. Performance (especially start-up time). Static type checking would help a
>>lot here, I think.
>
>Startup time is certainly something I intend to keep in mind. 
>It is relevant to two use cases I am particularly interested in 
>supporting better than current E does:
>• code in web pages (the common form of distributed computing)
>• command-line utilities and other programs following the launch, do something, exit pattern.
>
>I believe most of the startup time in current E implementations 
>is in loading code (improvable by precompilation, if you have a 
>place to stash the compile output) and in creating the objects 
>in a vat (improvable by keeping the core code smaller and 
>improving execution speed).
>
>Could you explain how you expect static type checking to help startup time?

Java failed as a language for users because of its slow startup. 
Since E was built on the Java virtual machine, it had the same 
problem. Since Java is statically typed, I don't see how having 
static types will help with the startup time.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, 
CA 95032


_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang