#26 [RFC] PKCS11Constants -- JDK11 Support
Closed: fixed 5 years ago Opened 5 years ago by cipherboy.

As mentioned by @emaldonado in issue#15, we're needing to support JDK11 as multiple distributions are moving towards it. Currently it is available in F28+ with the goal of making F30 (current rawhide) being the first release to use JDK11 by default. This is documented in Fedora.

One of the biggest changes is that sun.security.pkcs11.wrapper.PKCS11Constants is no longer exported and available for use outside of the JDK. This means that our tests and our consumers cannot rely on it.

@emaldonado proposed two workarounds:

  1. Use the version in NSS to generate our own version of this header. This will likely have to be done programmatically such that when NSS updates this file, we can too.
  2. Use the version in JDK and pull it in-tree, updating it as necessary.

The cons with approach 1 is that we'll have to write parsing logic to convert a C header file into a Java class. This makes me favor approach #2. We'd need to consult with Legal to ensure that this is OK as it appears to use a combination of a modified BSD-4 clause (+5 clause saying we have to rename it from what they originally called it) and whatever license the JDK is released under.

Pending Legal approval though, I'd recommend the following:

  • Under samples, create a new directory, PKCS11Constants, and include files which track each of the major JDK versions (JDK 8 and higher).
  • Create a script which automatically updates the contents of the samples/PKCS11Constants directory from the contents of the OpenJDK source trees. This might need to make minor adjustments so that it appears correctly in our tree. (e.g., change the package)
  • Update the build scripts to detect the JDK version and place the appropriate Java file in org/mozilla/jss/pkcs11/PKCS11Constants.

What this achieves is the following:

  • Any user who relies on the Sun version can update their include and use the version in JSS without other changes.
  • It can be applied to current JSS versions so users can update once and then upgrade to newer JDK versions as they want.
  • It mirrors the version the JDK ships, so if the user chooses to use our header, it'll be equivalent to whatever they have already, regardless of whether or not it is accessible to them.

The downsides are:

  • Legal advice is necessary.
  • It is a file we have to keep up to date and track against the JDK (potentially we can use automation to detect differences and open PRs as necessary).
  • We'd also have to make sure the in-tree automation is kept up to date and doesn't fail.

Thoughts?

/cc: @mharmsen, @cfu, @jmagne, @edewata, @dmoluguw, @emaldonado


I do agree that workaround 2 is easier than 1. It isn't easy though and will require some work to partially automate the sync up of ours with the one from openJDK and know when we need to update.

@cipherboy pointed me to this site
http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java

The problem with this page is that if download it via 'wget' it comes with a lot of HTML stuff on it. I haven't found the location of the actual source repository yet. From what I read it's a mercurial one. In the meantime I found a temprary workaround to get the file in a clean way. This is what I did.

  • Go to https://hg.openjdk.java.net/jdk/jdk11/
  • On the left side is an archive list. I picked the bz2 one and a download started.
  • Ended up with it at ~/Downloads/jdk11-1ddf9a99e4ad.tar.bz2
  • Double-click on it (or use tar xvzf) to extract it. Its big - the whole JDK.
  • I then cd ~/Dowloads/jdk11-1ddf9a99e4ad
    ```
    $ tree ./src/ | grep PKCS11Constants.java

    │   │   │   ├── PKCS11Constants.java
    ```

    confirms that it's included.

  • To find it
    $ find . -name PKCS11Constants.java ./src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java

  • I can now compare with the one we have.

  • Ours is in synch with this one, except for a package line I changed and many
    blank lines that we should get rid off.
  • Easy with cd to where we have ours and do sed -i '/^\s*$/d' PKCS11Constants.java will get rid of the unwanted empty lines.

Just to us started, a lot more work remains.

(edit: formatting by @cipherboy)

For reasons of interoperability with NSS, I decided to take the alternate approach and generate PKCS11Constants from NSS's pkcs11t.h. This has been opened as PR here:

This then has been finished in a different branch:

These later two have been tested together and verified to work.

I'd like feedback on the approach before continuing. In particular, I'd like to know:

  • If we want to try and preserve comments in the NSS source code
  • If we want to add new comments linking each constant to where in the source code it was found
  • If we want to add or run a comparison test against Java's version on JDK8
  • If we want to add this into a 4.5.1 release or if we should wait for 4.6 or 5.x since this is technically backwards compatible (pending the previous bullet point's testing).

Thoughts?

/cc @emaldonado @dmoluguw @jmagne @edewata

Metadata Update from @cipherboy:
- Custom field component adjusted to None
- Custom field feature adjusted to None
- Custom field origin adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

5 years ago

I'm closing this as fixed in favor of the pull request https://github.com/dogtagpki/jss/pull/41 and @emaldonado's JDK11 tracking bug: https://pagure.io/jss/issue/15

The RFC portion is complete: maintaining a Java version from NSS's library will be easy enough and automated so we can stay on top of changes there.

Metadata Update from @cipherboy:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata