Bug 1332867

Summary: Unexpected java.lang.InternalError in sun.security.ec.SunEC when Security.removeProvider("SunPKCS11-Solaris");
Product: [Fedora] Fedora Reporter: Florian Morgan <florian.morgan>
Component: java-1.8.0-openjdkAssignee: Andrew John Hughes <ahughes>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 23CC: ahughes, dbhole, jerboaa, jvanek, msrb, omajid, sgehwolf
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-09 12:19:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Florian Morgan 2016-05-04 09:04:48 UTC
Description of problem:
When I call Security.removeProvider("SunPKCS11-Solaris") in Java, a java.lang.InternalError is thrown in sun.security.ec.SunEC.

This is a regression as the exception is not thrown in base version of java-1.8.0-openjdk-devel (1.8.0.60-14.b27.fc23).

Version-Release number of selected component (if applicable):
1.8.0.91-2.b14.fc23

How reproducible:
Always.

Steps to Reproduce:
1. dnf install -y java-1.8.0-openjdk-devel
2. dnf info java-1.8.0-openjdk-devel, make sure version is 1.8.0.91-2.b14.fc23
3. java -version, make sure version is openjdk version "1.8.0_91"
4. Create Test.java with the following content:
import java.security.Security;

public class Test {
  public static void main(String args[]) throws SecurityException {
    Security.removeProvider("SunPKCS11-Solaris");
  }
}
5. javac Test.java
6. java Test

Actual results:
Exception in thread "main" java.lang.InternalError
	at sun.security.ec.SunEC.initialize(Native Method)
	at sun.security.ec.SunEC.access$000(SunEC.java:49)
	at sun.security.ec.SunEC$1.run(SunEC.java:61)
	at sun.security.ec.SunEC$1.run(SunEC.java:58)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.security.ec.SunEC.<clinit>(SunEC.java:58)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221)
	at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
	at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
	at sun.security.jca.ProviderList.loadAll(ProviderList.java:282)
	at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299)
	at sun.security.jca.Providers.getFullProviderList(Providers.java:173)
	at java.security.Security.removeProvider(Security.java:440)
	at Test.main(Test.java:5)

Expected results:
Nothing (empty console output, this is normal as the program doesn't do anything usefull besides desactivating "SunPKCS11-Solaris").

Additional info:
When installing with base version "dnf --disablerepo updates install -y java-1.8.0-openjdk-devel" it works fine.

Tests were done in a docker container with the latest fedora:23 image pulled from docker.io.

Comment 1 Severin Gehwolf 2016-05-04 11:38:07 UTC
I cannot reproduce this:
$ rpm -q java-1.8.0-openjdk-devel
java-1.8.0-openjdk-devel-1.8.0.91-2.b14.fc23.x86_64

Using this:

import java.security.Security;

public class TestSecurityProviders {

    public static void main(String[] args) {
        System.out.println(System.getProperty("java.version"));
        try {
            Security.removeProvider("SunPKCS11-Solaris");
            System.out.println("PASS!");
        } catch (Exception e) {
            System.out.println("Fail!");
        }
    }

}

It prints:
1.8.0_91
PASS!

The stack trace you've provided suggests that it fails to *load* the SunEC provider, which uses system nss native libs. Could you please paste output of the following command on the system where you reproduce this:

$ rpm -qa | grep nss-softokn

It should output something like this (minus debuginfo packages):
nss-softokn-3.23.0-1.0.fc23.x86_64
nss-softokn-devel-3.23.0-1.0.fc23.x86_64
nss-softokn-freebl-devel-3.23.0-1.0.fc23.x86_64
nss-softokn-debuginfo-3.23.0-1.0.fc23.x86_64
nss-softokn-freebl-3.23.0-1.0.fc23.x86_64

Comment 2 Severin Gehwolf 2016-05-04 16:19:45 UTC
This is most likely a duplicate of bug 1332456

Comment 3 Florian Morgan 2016-05-05 06:29:28 UTC
I cannot check currently (hollidays). I Will check on Monday. But I guess nss is not installed or it is on a wrong version (bug 1332455).
Thanks.

Comment 4 Florian Morgan 2016-05-05 06:30:32 UTC
(In reply to Florian Morgan from comment #3)
> I cannot check currently (hollidays). I Will check on Monday. But I guess
> nss is not installed or it is on a wrong version (bug 1332455).
> Thanks.

Oops I meant bug 1332456

Comment 5 Florian Morgan 2016-05-09 12:16:55 UTC
I confirm it's a duplicate of bug 1332456, nss is in version 3.22.2-1.0 in my configuration:

$ rpm -qa | grep nss-softokn
nss-softokn-freebl-3.22.2-1.0.fc23.x86_64
nss-softokn-3.22.2-1.0.fc23.x86_64
$ rpm -q nss
nss-3.22.2-1.0.fc23.x86_64

When I update with "dnf upgrade nss", nss updates to "3.23.0-1.0":

$ rpm -qa | grep nss
nss-softokn-freebl-3.23.0-1.0.fc23.x86_64
nss-util-3.23.0-1.0.fc23.x86_64
nss-softokn-3.23.0-1.0.fc23.x86_64
nss-3.23.0-1.0.fc23.x86_64
libsss_nss_idmap-1.13.4-2.fc23.x86_64
nss-sysinit-3.23.0-1.0.fc23.x86_64
openssl-libs-1.0.2h-1.fc23.x86_64
nss-tools-3.23.0-1.0.fc23.x86_64
$ rpm -q nss
nss-3.23.0-1.0.fc23.x86_64

And then, the problem won't reproduce, the Java program runs fine without error.

Comment 6 jiri vanek 2016-05-09 12:19:33 UTC
so it is https://bugzilla.redhat.com/show_bug.cgi?id=1332456

*** This bug has been marked as a duplicate of bug 1332456 ***