Java cryptography and free distributions

The problem first came up in February: the Red Hat Directory Server developers would like to include the Java Security Services module in the Fedora distribution. The code, it seems, is free, but there is still a problem: the Java virtual machine requires that all Java Cryptography Extension providers (of which JSS is one) to be signed with a Sun-approved key. If an application tries to use a JCE module which lacks the requisite signature, the whole thing comes crashing down - an experience which probably differs from what the user had in mind. In practice, this limitation means that users either use the signed version obtained from Sun, or do not use JSS at all.

Warren Togami recently posted a couple of possibilities for how Fedora might be able to ship JSS. They were:

• The Fedora team builds the JSS module, then compares it to the Sun-signed version. Assuming they match, Fedora has proved that it can rebuild the software. So the project can declare Mission Accomplished, dump the module it just built, and ship Sun's version. A variation on this approach suggested later on involved having Red Hat obtain an approved key and sign the modules that Fedora would distribute; in this way, Fedora could add its own modifications.

• Fedora ships an unsigned version of JSS. Applications would then have to be recoded to load the module in a way which shorts out the signature check. Any applications not fixed up in this way would fail.

The first option, at first blush, would appear to work. Fedora would be able to build its own module and ship the source. It falls down, however, as soon as a Fedora user tries to make a change; that user will not be able to rebuild the patched module in a way that will actually work. Derivative distributions would run into the same problem. As a result, it would appear that Fedora stopped considering this option fairly quickly.

Not signing the module at all has obvious problems as well. It seems likely that many potential JSS users have their own applications in mind. If those applications do not work, they will rightly see Fedora as not having support for the features they are looking for.

Other alternatives have been considered; one is to emphasize the use of the GCJ compiler and try to steer users away from Sun's virtual machine. That approach would certainly offer a higher degree of freedom, at the cost of not really providing what many Java users appear to want. Additionally, not everybody is convinced that GCJ has achieved the level of maturity that many users would expect.

In an interesting way, this is really just the Tivo problem under a different guise. Locked-down hardware refuses to run software which lacks the expected signatures. In this case, we have virtual hardware, in the form of the Java virtual machine, which is doing the same thing. The result is the same as well: the software is available and nominally free, but the users of that software cannot create their own versions and expect to be able to run them.

If Sun follows through on its desire to move to GPLv3, and if that license retains its requirement that any needed signing keys be distributed with the source, Sun may find itself in an interesting position. It is hard to see how the current policy would be compliant with the new GPL's requirements.

The upcoming GPL Java release would appear to be the best hope for distributors trying to deal with this situation. Once the code is free, distributors can patch it to make the whole of Java distributable as free software. So the real solution to shipping JSS with a distribution which insists on freedom would appear to be to wait for a free Java.

Index entries for this article
Security	Signing code

---

to post comments