Illegal reflective access operation to constructor sun.security.provider.Sun()

[llech]

Sorry if I post the duplicate, but to my surprise, I couldn't find any issue for illegal reflective access...

My program is using bcprov-jdk15on version 1.61

After starting it with JDK 12 I've got the following warting:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.bouncycastle.jcajce.provider.drbg.DRBG (file:/home/javar/lib/bcprov-jdk15on-1.61.jar) to constructor sun.security.provider.Sun()
WARNING: Please consider reporting this to the maintainers of org.bouncycastle.jcajce.provider.drbg.DRBG
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

The library is still working, but it is suggested, such illegal access might be blocked in next JDK versions.

It might be a tip of an iceberg, because JDK reports only first illegal access.

[bcgit]

Interesting,I've fixed it so you should no longer see the exception (funnily enough it's code for pre-1.9 JVMs that triggers this, so it was a simple change).

It's now in the latest beta (162b13 or later)

https://downloads.bouncycastle.org/betas/

[pgnd]

@bcgit

fyi, I've bcprov-jdk15on version 1.62 release installed ...

and am still seeing this^^ behvior on app launch (fwiw, currently, 'kcadm.sh' from keycloak)

afaict (?), nothing adverse ... other than the warning

[bcgit]

What is the text of the messsage?

[pgnd]

as example, if 'app' is keycloak v7.0.0's "kcadm.sh",

/opt/keycloak/bin/kcadm.sh get users \
 --target-realm=myrealm \
 --offset 0 --limit 1

	Picked up JAVA_TOOL_OPTIONS: -Djava.security.properties=/etc/java/java.security.local
	WARNING: An illegal reflective access operation has occurred
	WARNING: Illegal reflective access by org.bouncycastle.jcajce.provider.drbg.DRBG (file:/opt/keycloak/bin/client/keycloak-admin-cli-7.0.0.jar) to constructor sun.security.provider.Sun()
	WARNING: Please consider reporting this to the maintainers of org.bouncycastle.jcajce.provider.drbg.DRBG
	WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
	WARNING: All illegal access operations will be denied in a future release
	[{
	 "id" ...

where, atm

cat /etc/java/java.security.local
	security.provider.13=org.bouncycastle.jce.provider.KeycloakProvider
	security.provider.14=org.bouncycastle.jce.provider.BouncyCastleProvider
	security.provider.15=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
	security.provider.16=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
	keystore.type=bks

otoh, if I

	> /etc/java/java.security.local

then

/opt/keycloak/bin/kcadm.sh get users \
 --target-realm=myrealm \
 --offset 0 --limit 1

	Picked up JAVA_TOOL_OPTIONS: -Djava.security.properties=/etc/java/java.security.local
	[{
	 "id" ...

[bcgit]

It is not possible to use the BouncyCastleFipsProvider and the BouncyCastleProvider in the same class path. The error is coming from BouncyCastleProvider but I suspect there is an earlier version in the class path somewhere. You'd only see this is SecureRandom.getInstanceStrong() does not exist or there's an exception trying to access it (which is probably possible given that the two BC provider jars will not get along).

[pgnd]

fwiw, reducing to just

cat /etc/java/java.security.local
	security.provider.13=org.bouncycastle.jce.provider.BouncyCastleProvider
	keystore.type=bks

doesn't cure the issue; WARNINGS appear as above.

[dghgit]

There's still something odd about this - if SecureRandom.getInstanceStrong() exists in the JVM you shouldn't see the warning as the access will never take place. Are you absolutely sure another version of BC hasn't crept into the classpath somewhere? Also which JVM is this on?

[pgnd]

I agree about the 'odd' bit.

There's 'only one' system-wide version of BC installed -- by me. That's v1.62, into the usual "/usr/share/java/bc*.jar" locations.

That said, the reason I'm trying to get this to behave is that keycloak currently includes BC 1.60 -- supposedly loaded dynamically at runtime as a jboss module -- and affects the running server.

Whether that 'creeps in' somewhere/how -- TBH, I'm not yet sure. Still poking around trying to figure out what's what ...

Also which JVM is this on?

ATM, here

java -version
Picked up JAVA_TOOL_OPTIONS:  -Djava.security.properties=/etc/java/java.security.local
openjdk version "12.0.2" 2019-07-16
OpenJDK Runtime Environment (build 12.0.2+10-suse-lp151.41.1-x8664)
OpenJDK 64-Bit Server VM (build 12.0.2+10-suse-lp151.41.1-x8664, mixed mode)

[pgnd]

@dghgit

if SecureRandom.getInstanceStrong() exists in the JVM

not sure if this is a useful check for that,

cat test.java
	import java.security.Provider;
	import java.security.Security;
	import java.util.Enumeration;
	public class MainClass {
	  public static void main(String[] args) throws Exception {
	    try {
	      Provider p[] = Security.getProviders();
	      for (int i = 0; i < p.length; i++) {
	          System.out.println(p[i]);
	          for (Enumeration e = p[i].keys(); e.hasMoreElements();)
	              System.out.println("\t" + e.nextElement());
	      }
	    } catch (Exception e) {
	      System.out.println(e);
	    }
	  }
	}

java ./test.java | grep -i random
        SecureRandom.DEFAULT
        SecureRandom.NONCEANDIV
        SecureRandom.NativePRNG ThreadSafe
        SecureRandom.NativePRNGNonBlocking ThreadSafe
        SecureRandom.SHA1PRNG
        SecureRandom.NativePRNG
        SecureRandom.NativePRNGNonBlocking
        SecureRandom.DRBG ImplementedIn
        SecureRandom.SHA1PRNG ThreadSafe
        SecureRandom.SHA1PRNG ImplementedIn
        SecureRandom.DRBG
        SecureRandom.NativePRNGBlocking ThreadSafe
        SecureRandom.DRBG ThreadSafe
        SecureRandom.NativePRNGBlocking

[dghgit]

It's in Java 12 - it appears it points at the blocking NativePRNG which is what would be expected.

[pgnd]

whatever the issue, so far it appears to be unique to 'kcadm.sh' usage ...

jboss-cli.sh, also from the keycloak distrib, isn't similarly complaining.