OpenJDK (>=7) supports various ECC algorithms as indicated in http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC Please enable ECC support in Fedora packages now.
The in-tree copy of ECC still shouldn't be enabled; it results in a bundled version of NSS. The correct way to fix this (as has been done in Debian & Gentoo for years) is to enable the NSS provider at the lowest priority. When NSS gains ECC support (this bug should depend on that), OpenJDK will then gain it automatically.
The NSS provider isn't really a solution because of this bug: http://bugs.sun.com/view_bug.do?bug_id=6913047 As it stands it is unlikely that the NSS provider is going to be fixed.
Does that occur when the NSS provider is at any priority or just the highest? The SunEC provider is basically a big chunk of code copied from NSS. Are you sure it doesn't exhibit the same issues? Using the NSS provider to handle ECC has been the solution on Debian & Gentoo since around 2010. The Sun EC provider hasn't been used by any FOSS distro and is potentially a legal & security minefield.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This package doesn't exist in Fedora 22, does it? This could be enabled in versions of Fedora that still have java-1.7.0-openjdk in the same way it has been in RHEL.
No fedora have openjdk 7 since today. One guy is running private copr repo, but he is merging from CentOs. So if we fix it in rhel, in time it will bubble also without any more of our attendance.
Ok, let's file this against OpenJDK 8 instead then, where the problem also exists.
*** Bug 1225576 has been marked as a duplicate of this bug. ***
*** Bug 1019553 has been marked as a duplicate of this bug. ***
In the interim, Fedora could enable the PKCS11 provider at the lowest priority. While it has the issue mentioned in comment #2, that's only an issue on long running processes and I believe is better than having no ECC support at all, especially as use on Fedora is likely to be client TLS connections and not servers. Due to the way the PKCS11 provider has been altered in OpenJDK 8, the SunEC provider shell does need to be present for it to work (they share common code in a rather bizarre way). The native implementation code for the SunEC provider should still be deleted. You'll also need to alter the list of available curves as we did in 7 (see the 7 RPM patches).
Hi, i stumbled upon this because I wanted to run the latest jetty as HTTP2 server, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=468106#c12
The PKCS11 provider is known to leak memory, but the SunEC provider is not known to leak memory. I haven't looked, but as far as I'm aware the SunEC provider does not use the PKCS11 interface, and the memory leak is entirely in the interface between Java and native code. We should try the SunEC provider.
java-1.8.0-openjdk-1.8.0.72-7.b15.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9fd9fc27d8
java-1.8.0-openjdk-1.8.0.72-7.b15.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9fd9fc27d8
java-1.8.0-openjdk-1.8.0.72-7.b15.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.