Description of problem: For OpenJDK to provide elliptic curve support, there is a choice of two providers: the PKCS11 provider, using NSS, or the in-tree SunEC provider, which duplicates code from NSS. The former is out of the question, because of memory leak issues [0], so we've been looking at whether the SunEC provider can be used by reusing the system copy of NSS. Pretty much all the files in the SunEC provider exist in NSS 3.15.5, but some of the code isn't currently exposed by the RPMs. $ ls jdk/src/share/native/sun/security/ec/impl/ ec2_163.c ec2_mont.c ecl.c ecl.h ecp_224.c ecp.h mp_gf2m.c mpi.h mpprime.h ec2_193.c ec.c ecl_curve.c ecl_mult.c ecp_256.c ecp_jac.c mp_gf2m.h mpi-priv.h oid.c ec2_233.c ecc_impl.h ecl-curve.h ecl-priv.h ecp_384.c ecp_jm.c mp_gf2m-priv.h mplogic.c secitem.c ec2_aff.c ecdecode.c ecl-exp.h ec_naf.c ecp_521.c ecp_mont.c mpi.c mplogic.h secoidt.h ec2.h ec.h ecl_gf.c ecp_192.c ecp_aff.c logtab.h mpi-config.h mpmontg.c As you may know, the elliptic curve library was contributed to NSS by Sun [1] and, with the OpenJDK version, they seem to have gone back to the original library for both ECL and the dependent MPI library, then cobbled on bits of NSS (secitem.c & secoidt.h are from lib/util in NSS, ecdecode.c from lib/softoken). So, all in all, the native code for SunEC is a bit of a Frankenstein's monster. The most important difference is ecl-curve.h, where the OpenJDK version defines a vast number of curves beyond Suite B, whereas NSS fails with #error if NSS_ECC_MORE_THAN_SUITE_B is defined (the OpenJDK build defines this). We can't ship this version of ecl-curve.h in Fedora at present. With a few changes to OpenJDK, a build of NSS and nss-softokn-freebl-devel installed, I was able to build the SunEC provider against the system NSS. To do this in an OpenJDK RPM, we'd need an additional NSS RPM that provides the following: * softoken.h * lowkeyti.h * softoknt.h * libsoftokn.a and ideally dependent on nss-softokn-freebl-devel. Version-Release number of selected component (if applicable): The Fedora installation I used was F16, so had NSS 3.14.1, but the local build was 3.15.5 as noted above. The code concerned doesn't appear to have changed much. The NSS 3.15.5 version has some floating point enhancements which are absent in the OpenJDK version. Additional info: [0] http://bugs.sun.com/view_bug.do?bug_id=6913047 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=195135
Andrew, what are you grabbing out of libsoftokn? It think it might be cleaner to move those to freebl. bob
EC_DecodeParams, defined in softoken.h and provided in libsoftokn.a. The others it requires: EC_NewKeyFromSeed ECDSA_SignDigestWithSeed ECDSA_VerifyDigest ECDH_Derive are all in blapi.h and freebl.a.
Elio, let's move EC_DecodeParams to freebl. I would suggest moving it to nssutil, but it requires freebl headers. We'll need to move EC_FillParams as well, so it's probably good to move all of ecdecode.c bob
Any progress on this? We'd like to be able to ship SunEC soon in the OpenJDK RPMs. Thanks.
Andrew, I have discussed this further with Bob. This is a code refactoring where we are moving ecdecode.c from softoken to freebl and also the tree prototypes from softoken.h to blapi.h. I will shortly open an upstream bug and attach the relevant patch for review. We must wait until the patch is approved and applied upstream before I can apply it in fedora in order to preserve API/ABI compatibilty. I don't have to wait until the next release of nss upstream only until it has been applied. It shouldn't take too long for that to happen. I hope you can wait a few more days. I created a fedora private branch private_emaldona_bz1075702 for this work and made a test scratch http://koji.fedoraproject.org/koji/taskinfo?taskID=6708176 where I have applied the patch I plan to submit upstream. It would be nice if you could test this with the SunJCE provider work you have in progress. That we make sure we haven't overlooked anything. Elio
Created attachment 882799 [details] Refactor ecdecode from softoken to freebl This my work in progress and what was used for the scratch build. I still have to test some more and will discussing with Bob some changes that I am not sure is the best way to accomplish what I need, freebl/config.mk, and also about versioning.
Comment on attachment 882799 [details] Refactor ecdecode from softoken to freebl I still have to test on Mac OX and Windows as this is intended for upstream. This is still a work in progress. In particular, I suspect that the changes to freebl/config.mk may not be the correct ones, or not placed in the right place, for platforms others than fedora.
Created attachment 884160 [details] Refactor ecdecode from softoken to freebl V2 This one is the one I will submit upstream based on guidance that Bob provided.
You'll need to bump the version number in loader.h as well.
Created attachment 886221 [details] Refactor eccdecode from softoken to freebl patch committed upstream https://hg.mozilla.org/projects/nss/rev/f3e3b8b185fa
Sorry for the delayed response. We've been working on a security update over the past week or so. Wow, I'm impressed things moved on so quickly! I'm working on getting a test build up and running with the new version. Will the upstream version also be 3.16 or is that just the local Fedora-patched version?
(In reply to Andrew John Hughes from comment #11) > Will the upstream version also be 3.16 or is that just the local > Fedora-patched version? The upstream version will be nss-3.16.1. Luckily, it applied unmodified on 3.16.0 as we currently have in fedora.
The headers are now fine, but there are still some linking issues. If the libs from pkg-config --libs nss-softokn -lfreebl3 -lnssdbm3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl are used, I get: /notnfs/nighttester/icedtea7-target-testing/openjdk.build-boot/tmp/sun/sun.security.ec/obj64/ECC_JNI.o: In function `FreeECParams': /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:55: undefined reference to `SECITEM_FreeItem' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:56: undefined reference to `SECITEM_FreeItem' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:57: undefined reference to `SECITEM_FreeItem' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:58: undefined reference to `SECITEM_FreeItem' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:59: undefined reference to `SECITEM_FreeItem' /notnfs/nighttester/icedtea7-target-testing/openjdk.build-boot/tmp/sun/sun.security.ec/obj64/ECC_JNI.o:/notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:60: more undefined references to `SECITEM_FreeItem' follow /notnfs/nighttester/icedtea7-target-testing/openjdk.build-boot/tmp/sun/sun.security.ec/obj64/ECC_JNI.o: In function `Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair': /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:90: undefined reference to `EC_DecodeParams' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:102: undefined reference to `EC_NewKeyFromSeed' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:131: undefined reference to `SECITEM_FreeItem' /notnfs/nighttester/icedtea7-target-testing/openjdk.build-boot/tmp/sun/sun.security.ec/obj64/ECC_JNI.o: In function `Java_sun_security_ec_ECKeyPairGenerator_getEncodedBytes': /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:158: undefined reference to `SECITEM_FreeItem' /notnfs/nighttester/icedtea7-target-testing/openjdk.build-boot/tmp/sun/sun.security.ec/obj64/ECC_JNI.o: In function `Java_sun_security_ec_ECDSASignature_signDigest': /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:200: undefined reference to `EC_DecodeParams' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:222: undefined reference to `ECDSA_SignDigestWithSeed' /notnfs/nighttester/icedtea7-target-testing/openjdk.build-boot/tmp/sun/sun.security.ec/obj64/ECC_JNI.o: In function `Java_sun_security_ec_ECDSASignature_verifySignedDigest': /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:299: undefined reference to `EC_DecodeParams' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:309: undefined reference to `ECDSA_VerifyDigest' /notnfs/nighttester/icedtea7-target-testing/openjdk.build-boot/tmp/sun/sun.security.ec/obj64/ECC_JNI.o: In function `Java_sun_security_ec_ECDHKeyAgreement_deriveKey': /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:370: undefined reference to `EC_DecodeParams' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:381: undefined reference to `ECDH_Derive' /notnfs/nighttester/icedtea7-target-testing/openjdk-boot/jdk/make/sun/security/ec/../../../../src/share/native/sun/security/ec/ECC_JNI.cpp:395: undefined reference to `SECITEM_FreeItem' If the static -lfreebl is added (which I had before and could live with), it reduces to just the SECITEM_FreeItem ones. It does show up as being present in /usr/lib/libfreebl3_so.usrmove~ so is this something which has been recently dropped? My own local install of NSS 3.16.0 does build against it with: -lfreebl -lsoftokn -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 (i.e. two static libraries, freebl.a and softokn.a)
(In reply to Andrew John Hughes from comment #13) > The headers are now fine, but there are still some linking issues. > > If the libs from pkg-config --libs nss-softokn > > -lfreebl3 -lnssdbm3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread > -ldl > > are used, I get: > ... link failures onmited Intead of -lfreebl3 you should use lfreebl as you stated next > If the static -lfreebl is added (which I had before and could live with), it > reduces to just the SECITEM_FreeItem ones. SECITEM_FreeItem is provided by nss-util. > > It does show up as being present in /usr/lib/libfreebl3_so.usrmove~ so is > this something which has been recently dropped? Notning has been removed. > > My own local install of NSS 3.16.0 does build against it with: > > -lfreebl -lsoftokn -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 > > (i.e. two static libraries, freebl.a and softokn.a) We install freebl.a but never softokn.a. The latter is for internal use only. $ rpm -ql nss-softokn-freebl-devel /usr/include/nss3/alghmac.h /usr/include/nss3/blapi.h /usr/include/nss3/blapit.h /usr/lib/libfreebl.a and libfreebl.a is meant for the use of glibc and crypograpinc modules only. In nss-softoen.spec I have this fragment: ......................... %package freebl-devel Summary: Header and Library files for doing development with the Freebl library for NSS Group: System Environment/Base Provides: nss-softokn-freebl-static = %{version}-%{release} Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release} %description freebl-devel NSS Softoken Cryptographic Module Freelb Library Development Tools This package supports special needs of some PKCS #11 module developers and is otherwise considered private to NSS. As such, the programming interfaces may change and the usual NSS binary compatibility commitments do not apply. Developers should rely only on the officially supported NSS public API. ................ The SunEC being a cryprographic provider qualifies you for membership on that club of PKCS #11 module developers. It's working for me with a crude and hacked application which I made based on one of our tools. I hope this helps.
Hmm... so I'm doing the right thing. Is the changed version now in rawhide? If so, I'll do a koji build against it and make sure it's not a local issue.
Yes, it's in Rawhide now, I applied the patch on 3.16.0 since 3.16.1 won't be out for several weeks. If you create a private branch for or give me an srpm I would be glad to try and help as much as I can if needed.
The important thing is to statically link against libsoftokn.a and I think you already link dnamically against libnssutil3.so. Don't think you need to link with libnss3.so but I am not 100% sure.
> The important thing is to statically link against libsoftokn.a err you mean libfreebl.a. There should be no statically linking against libsoftokn.a (which we don't package on purpose). > and I think you already link dnamically against libnssutil3.so. Yes, the will. > Don't think you need to link with libnss3.so but I am not 100% sure. Correct, they shouldn't have to link against libnss3.so (nor libsofton3.so).
> and libfreebl.a is meant for the use of glibc and crypograpinc modules only. Actually glibc links directly with libfreebl3.so. This usage counts as a 'cryptographic' module. They are doing their own crypto and just using our ECC helper functions.
nspr-4.10.5-1.fc20,nss-util-3.16.1-1.fc20,nss-softokn-3.16.1-1.fc20,nss-3.16.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/nspr-4.10.5-1.fc20,nss-util-3.16.1-1.fc20,nss-softokn-3.16.1-1.fc20,nss-3.16.1-1.fc20
nspr-4.10.5-1.fc19,nss-util-3.16.1-1.fc19,nss-3.16.1-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/nspr-4.10.5-1.fc19,nss-util-3.16.1-1.fc19,nss-3.16.1-1.fc19
Package nspr-4.10.5-1.fc20, nss-util-3.16.1-1.fc20, nss-softokn-3.16.1-1.fc20, nss-3.16.1-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nspr-4.10.5-1.fc20 nss-util-3.16.1-1.fc20 nss-softokn-3.16.1-1.fc20 nss-3.16.1-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6176/nspr-4.10.5-1.fc20,nss-util-3.16.1-1.fc20,nss-softokn-3.16.1-1.fc20,nss-3.16.1-1.fc20 then log in and leave karma (feedback).
nspr-4.10.5-1.fc20, nss-util-3.16.1-1.fc20, nss-softokn-3.16.1-1.fc20, nss-3.16.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Switched to using the libs from pkg-config --libs nss rather than nss-softokn and added -lfreebl manually. Builds now work: http://koji.fedoraproject.org/koji/taskinfo?taskID=6833307 (ignore the ARM failure; it's a timeout because it's so slow)
nspr-4.10.5-1.fc19, nss-util-3.16.1-1.fc19, nss-3.16.1-1.fc19, nss-softokn-3.16.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.