Re: E patches for review: ELoader, Scope.with, seedVat

On Thu, 2010-05-20 at 08:15 -0700, Mark Miller wrote:
> On Thu, May 20, 2010 at 6:44 AM, Thomas Leonard 
>         
>         For discussion:
>         
>         Can I remove ESecureRandom? "This class provides a
>         cryptographically
>         strong random number generator based on user provided sources
>         of entropy
>         and the MD5 hash algorithm." I'm guessing that the normal Java
>         version
>         is pretty good these days - is there any reason why E needs
>         its own
>         one?
>         
>         My particular reason for wanting to remove it is that the Java
>         version
>         lets you request a lower-security configuration that's much
>         faster for
>         testing, and I worry that the crypto stuff in E isn't actively
>         maintained.
> 
> I remember this came up at Electric Communities. Bill (cc'ed) did
> ESecureRandom. ESecureRandom wouldn't provide random bits until it
> could provide good ones.

I think Java's SecureRandom is the same? e.g.

http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom

> This led to longer startup times, which was frustrating during our
> rapid development cycle. Bill was repeatedly asked "We don't need high
> quality randomness during development. Can't you just give us a switch
> so that we can turn this off during development?" IIRC, Bill refused
> to provide a switch until we could build a development process that
> could ensure that this switch wouldn't accidentally be left on in the
> shipping product.
> 
> Whether I remember this accurately or not (Bill?), it has become one
> of my favorite stories about the proper attitude to security during
> software development.
> 
> Are there any remaining vestiges of this switch? What was the means of
> ensuring that this switch was not left on in the shipping product?
> Although I love the story, I never did become familiar with the
> specifics.

I haven't seen the switch, and updoc certainly doesn't use it. e.g.

$ cat intro.updoc 
? introducer.onTheAir()

$ time rune intro.updoc
updoc: started
intro.updoc:.
All tests passed.
rune two.updoc  6.57s user 0.34s system 9% cpu 1:14.13 total

Any it could have taken much longer, but I got bored of waiting and
started clicking the mouse a bit after a minute.

Although we hit this problem during testing, I guess it will be a
problem for "shipping products" too. A desktop application that takes
minutes to start isn't much use.


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk