[security-dev 01187]: Re: 6840752: Provide out-of-the-box support for ECC algorithms

[Andrew John Hughes]

2009/8/27 Vincent Ryan <Vincent.Ryan at sun.com>:
> Hello Andrew,
>
> Our original intention was to provide a Java implementation of ECC.
>
> However due to software patents already granted for ECC we were
> constrained in what we could reasonably resource and openly discuss.
>
> In the end we opted to reuse the NSS code from OpenSolaris (which was
> originally developed at Sun Labs and donated to OpenSSL and NSS).
>
> Although, on many non-Windows platforms, this does result in an existing
> system library being replicated in the JDK perhaps that issue can be
> solved in future by making use of modules.
>
>
>
> Andrew John Hughes wrote:
>> With this changeset:
>>
>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1ff7163fc5f7
>>
>> the new ECC was added to OpenJDK.  When I first read about this, I'd
>> assumed we were getting a Java-based implementation.  The final
>> changeset seem to just be an inclusion of the NSS code into the
>> OpenJDK codebase, which adds yet another case where a system library
>> is replicated internally (the others being libjpeg, libpng, zlib, lcms
>> and probably others I've missed).
>>
>> Is this correct? Were there local modifications to this code as well?
>>
>> As seems to be common practice with OpenJDK, this changeset just
>> appeared with very little, if any, public discussion.
>

Thanks for your reply, Vincent.

I've now had chance to look at the changeset in more detail, including
comparing it with the sources from my system NSS, and have a few more
questions:

  * Which version of NSS were these sources pulled from?  Running diff
-bu on them, and ignoring the additional copyright headers,
  there are still a large number of changes.  I suspect this is
because the version is older than my system copy (3.12.3); notably my
  testing shows it does not exhibit the bug discussed in
http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html
(which
  incidentally is still awaiting review).
  * Why was a new provider used instead of the existing
sun.security.pkcs11.SunPKCS11 provider?  I noticed this has not be
removed, yet
  it appears to provide duplicate functionality unless I'm mistaken.
This does perhaps mean we could fix the issues with this changeset
simply
  by allowing the ec subdirectory to be turned off, but there may be
something about the new provider I'm missing.
  * I notice that a number of algorithms are replaced with NULL.  I
assume there is some (perhaps legal) reason for this?

I'm afraid my current impression of this changeset is that it doesn't
help us with packaging OpenJDK for GNU/Linux distributions at all, but
instead makes things ten times worse as there is now a stale NSS to
contend with.  Not only are there the issues with bit rot I alluded to
last time, but as you mention in your reply there are legal issues
with EC support.  Notably, I've found that Fedora doesn't ship any EC
support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd
have to rip this out in packages for that distribution (and it's
dubious whether others should be shipping it).  IANAL, so I won't
comment further on such issues, but suffice to say this changeset
significantly reduces the options for handling NSS support downstream.
 In contrast, the existing support in 1.6 is almost ideal, once you've
discovered how it works; the distro packager can choose whether to
enable support or not and they don't have to worry about rotting
security code in OpenJDK.  Maybe I'm missing something but this makes
me think this would have been better as a local addition to Sun's
proprietary builds rather than adding it to OpenJDK.

I try to be as positive as I can about the OpenJDK project, but I'm
sorry to say that changesets like this don't help.  I actually find
them quite depressing.  As I said in my previous email, there appears
to have been no discussion of this change; it was merely committed
with no public review and appeared in b70.  Meanwhile, myself and
other external contributors have to spend days trying to get replies
to emails to even get a simple bug fix in (I've lost count of how many
I still have waiting; there must be at least four or five).  That's
just not fair and doesn't bode well for a successful community
project.

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8