[security-dev 00916]: Re: Cleaning up crypto support] (original) (raw)

Brad Wetmore Bradford.Wetmore at Sun.COM
Wed Jun 24 15:12:09 UTC 2009

(I sent to the wrong alias, resending to open list-darn Thunderbird auto-completion has struck again. I will forward Mark's reply in a minute.)

Hi Mark,

On Thu, 2008-11-20 at 18:54 +0100, Mark Wielaard wrote:

Mark Wielaard wrote:

It seems this is working out good for the GNU/Linux distros based on the latest IcedTea6 releases, so getting this upstream would be nice. Anything I can do to help with that?

Just to make sure this doesn't get forgotten

No, definitely not forgotten, but not near the top of the stack either. It's been far too long, so I'll bite the bullet tonight...

I also filed it as: https://bugs.openjdk.java.net/showbug.cgi?id=100062

Perfect! That's exactly what the Bugzilla instance is for.

Let me start with my usual warning/advice for anyone coming late to the crypto party (I apologize to the older hands who already know this): Even if the code compiles/runs without you doing anything, there are still complex regulations that you will need to closely follow. They vary from country to country, and it is your responsibility as a porter to make sure your implementation is playing by any applicable rules. Always consult qualified export/import counsel when doing anything with crypto (e.g. signing provider jar files, provider verification/authentication, open cryptographic interfaces, obfuscation, limited policy files, etc.). Running afoul of regulations is not a good way to start your day.

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.

You've noticed the JarVerifier class is basically empty, and thus it appears that a lot of this code is useless. In the closed repository, there is another JarVerifier class with real code, but we could not open source it. (As Dalibor is so fond of saying: "Death to all closed code..." but unfortunately, we're stuck.) What I had to do was introduce conditional compilation via the makefiles: if the file exists in both the closed and open repositories, compile only the closed one, otherwise use the open version. In the open code, the "hook" targets are essentially stubs and return quickly; in the closed code, there's a lot more to do.

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.

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.

Always consult your export/import counsel when doing anything with crypto.

Thanks,

Brad

More information about the security-dev mailing list