Bug 1332867 - Unexpected java.lang.InternalError in sun.security.ec.SunEC when Security.removeProvider("SunPKCS11-Solaris");
Summary: Unexpected java.lang.InternalError in sun.security.ec.SunEC when Security.rem...
Keywords:
Status: CLOSED DUPLICATE of bug 1332456
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk
Version: 23
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Andrew John Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-04 09:04 UTC by Florian Morgan
Modified: 2016-05-09 12:19 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-09 12:19:33 UTC
Type: Bug


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.