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

[Brad Wetmore]

(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/show_bug.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.

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

Thanks,

Brad