[security-dev 00917]: Re: Cleaning up crypto support]

[Brad Wetmore]

-------- Original Message --------
Subject: Re: Cleaning up crypto support]
Date: Wed, 24 Jun 2009 08:25:31 +0200
From: Mark Wielaard <mjw at redhat.com>
To: Brad Wetmore <Bradford.Wetmore at Sun.COM>
CC: JDK <XXXXXXXXXXXXXXXXXXXXXXXXX at sun.com>
References: <4A41A4E5.7000604 at sun.com>

Hi Brad,

Any reason not just to continue this discussion on the public lists?

On Tue, 2009-06-23 at 21:00 -0700, Brad Wetmore wrote:
>  > There is still a lot of cruft in the codebase for preventing the usage
>  > of certain crypto algorithms or key-sizes. And we were actually
>  > shipping restricted policies preventing people from using unlimited
>  > crypto. Oops.
> 
> With the above out of the way, I understand and appreciate the 
> motivation for what you'd like to do.  However, I don't think this is a 
> fix I can take in its current form.

OK, lets see how we can get it into a form that is acceptable.

> Somehow we need to keep the code available, while allowing those that 
> don't want this functionality to have it be optional.
> 
> Believe it or not, we occasionally get product requests for *WEAKER* 
> crypto policy files to satisfy some country's import requirements.  I 
> don't know exactly how many JDK implementations care about limited 
> crypto/exemption mechanisms/signed providers, but that number is 
> definitely greater than one.  Just stripping out these large chunks of 
> code would require those implementations put it all back in.  As you 
> note, that's a fair amount of code.  Duplicating large chunks of 
> Cipher/JCESecurity/etc. in the "closed" area isn't the answer either, 
> open implementations should have access to the same code/functionality 
> if they need it.

OK, I thought by concentrating on just Cipher and JCESecurity that was
the simplest approach, since then it is just those two classes that need
extra work for those that wish to create closed restricted crypto, while
keeping the code clean for those that just base their work on the open
code.

> One of the reasons I haven't responded yet is that I was trying to think 
> of a nice way to do minimal compile-type options that would allow both 
> goals without adding too many hooks or complicated Makefiles, but I'm 
> coming up short on both brilliant ideas and time.  This is the one place 
> where I'd give my left earlobe for #ifdef's in Java.  We used to do this 
> in Solaris all the time.

Most people will never have to deal with any of the closed non-GPL code,
and so will never even be able to create any restricted crypto since
they will provide the full sources to their users as it should be. So it
is somewhat hard to see what you want to keep and why, since all I have
is the public code and none of it seems very effective in "closing down"
crypto in the first place (and obviously it will not if the end user
gets the source code anyway).

So what my patch does is clean up the code so as far as I can see one
only needs one to replace two classes (Crypto and JCESecurity) if so
desired (it has been a very long time ago I wrote the patch though, so
maybe I overlooked something that I don't remember now). But you would
like to see more fine grained hooks. Could you describe which hooks you
want to keep ?

BTW. My first reason to write the patch was because the defaults caused
"restricted" crypto to not be available unless one installed some
(bogus) policy files. That wasn't something distros did, so end users
got a surprise since not all algorithms worked out of the box.

Cheers,

Mark