Re: Idle musings on doing E over again

On 2 October 2012 03:16, Bill Frantz <[email protected]> wrote:
> 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.

That's handy. But even without it, generating a self-signed
certificate to hold the public key works fine (it's just a bit
wasteful).

> 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.

Technically, maybe. But for adoption it's hard to convince people that
a non-standard crypto implementation will be OK. If there's a bug in
OpenSSL then:

1) it will get fixed promptly
2) the fix will get distributed (e.g. via the distributions)
3) it's not anyone's fault for choosing OpenSSL, because it's widely used

I don't think any of these are true for E's crypto.

I've only looked at Python and Java, but both provide easy access to
the server certificate used in a TLS connection.

> (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?

I meant that static typing would help for performance in general, not
startup specifically. I profiled E's startup a while back, but there
was nothing obviously the problem, just many little things.

> 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.

E's startup time is a lot worse than Java's (even though Java is
indeed far too slow):

$ time python hello.py
python hello.py  0.02s user 0.00s system 84% cpu 0.024 total

$ time java Hello
java Hello  0.06s user 0.02s system 98% cpu 0.082 total

$ time rune hello.e
rune hello.e  9.23s user 0.34s system 200% cpu 4.785 total


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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