I am creating a swing based application in Java which uses some encryption technique. But
javax.crypto.KeyGenerator.getInstance("AES", "BC") gives exception:
java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
at javax.crypto.SunJCE_b.a(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
So what is the problem?
edit jre\lib\security\java.security
add security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider
copy bc*.jar to jre\lib\ext
To expand on the comment from GregS, all JCE provider JARs must be signed before they will be trusted by your Java runtime.
BouncyCastle dutifully supplies signed JARs that will work without a problem. However, if you extract class files from this JAR, or recompile the source, it will remove the signature and cause Java to reject the code.
See this related SO question: How to sign a custom JCE security provider
For those finding this issue but actually using SpongyCastle, it might be interesting to know that on Android there is no such signature test and for your tests you can use SpongyCastle via the openJDK-8 as that doesn't care about signatures neither.
For reference, with SpongyCastle the error reads:
java.lang.SecurityException: JCE cannot authenticate the provider SC
More information in this issue
We have been suffering with the same issue for a few weeks and had tried a lot of the suggested steps to no avail. Providing our solution below so others don't have to suffer like we did!
We were attempting to use bcprov-ext-jdk15on-162.jar, added to classpath, included in JBoss lib directories, bundled with WAR, marked as provided and added to JBoss /lib directories but no luck.
In the end, we tried different versions of bouncycastle and found a less recent version who's signature could be verified by our particular Java version's jarsigner (1.5X).
Despite the jar's signature being verifiable by our Java version, when the .jar is packaged into a WAR the signature was invalidated somehow by JBoss.
In the end, the solution for us was to;
1. Add bouncycastle jar to JBoss classpath
2. Add 'org.bouncycastle.jce.provider.BouncyCastleProvider' to 'java.security' providers
3. Mark bouncycastle in your WAR as a 'provided' dependency
Once we had a version of the .jar on our classpath and were sure that our WAR was not packaging it in we were golden.
The issue seems to be tightly coupled to whatever Java/JBoss version you happen to be using. So if this solution does not work for you I would suggest to test different versions of bouncycastle with
jarsigner -verify <bouncycastle.jar>
There are lot of solutions to this problem but unfortunately nobody talks about the causing issue.
If you are generating an executable jar that has BC.jar in it(in form of any dependency) than this issue would occur if below condition matches:
Generating jar via eclipse's export option i.e. Export-> Runnable Jar File -> Libary Handling {extract required libraries into generated Jar}-> FINISH
Boom, now you have landed into trouble and you will face an error i.e. JCE can't authenticate the provider BC
The reason for above problem is, when you create a jar with option 1 than you are actually unpacking the BouncyCastle jar again that violates the security assosiated with BC. So, whenever you run it again java validates it and finds current BC.jar in your assosiated jar has an error.
So, guys make sure what you are doing is justified because by changing the JDK's security data that will make it work but not for everyone.
How to make it work?{This will work on local/personal machine only,not on every machine }
edit jre\lib\security\java.security file
add security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider
copy bc*.jar to jre\lib\ext
That's it.
For me the issue was bcprov-ext-jdk16.jar was being discarded by sbt assembly.
[warn] Merging 'META-INF/license/LICENSE.bouncycastle.txt' with strategy 'discard'
..
[warn] Merging 'META-INF/maven/org.jasypt/jasypt/pom.properties' with strategy 'discard'
[warn] Merging 'META-INF/maven/org.jasypt/jasypt/pom.xml' with strategy 'discard'
..
So I ended up using the bouncycastle.jar from -classpath as below,
java -Denvironment=dev -cp chat-server.jar:/Users/prayagupd/.ivy2/cache/org.bouncycastle/bcprov-ext-jdk16/jars/bcprov-ext-jdk16-1.46.jar com.chat.server.ChatServer
What also works is putting the bouncycastle.jar to $JAVA_HOME/jre/lib/ext,
cp /Users/prayagupd/.ivy2/cache/org.bouncycastle/bcprov-ext-jdk16/jars/bcprov-ext-jdk16-1.46.jar $JAVA_HOME/jre/lib/ext/
$ ls -l $JAVA_HOME/jre/lib/ext/
total 55208
-rw-r--r-- 1 root wheel 1887089 May 7 21:22 bcprov-ext-jdk16-1.46.jar
-rw-rw-r-- 1 root wheel 3860502 Sep 5 2017 cldrdata.jar
-rw-rw-r-- 1 root wheel 8286 Sep 5 2017 dnsns.jar
-rw-rw-r-- 1 root wheel 44516 Sep 5 2017 jaccess.jar
-rwxrwxr-x 1 root wheel 18610276 Sep 5 2017 jfxrt.jar
-rw-rw-r-- 1 root wheel 1179093 Sep 5 2017 localedata.jar
-rw-rw-r-- 1 root wheel 1269 Sep 5 2017 meta-index
-rw-rw-r-- 1 root wheel 2022735 Sep 5 2017 nashorn.jar
-rw-rw-r-- 1 root wheel 41672 Sep 5 2017 sunec.jar
-rw-rw-r-- 1 root wheel 274148 Sep 5 2017 sunjce_provider.jar
-rw-rw-r-- 1 root wheel 248726 Sep 5 2017 sunpkcs11.jar
-rw-rw-r-- 1 root wheel 68924 Sep 5 2017 zipfs.jar
FYI: instead of modifying java.security and copying jar to \jre\lib\ext, below steps resolved my issue as well.
add Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider()) in your class.
add provided scope to bcprov.*.jar dependency in pom.xml.
put bcprov.*.jar to your specific folder(e.g: \lib), then refer it when run the project.
Related
I made an android gluon app, testing the validity of the model before going "big boy".
I had some struggles, mainly due to how different a gluon app on desktop and mobile (android) react.
I was able to overcome all of them, except one.
When my app starts, i open some websockets connections and get this exception
[Thu Aug 11 08:39:13 CEST 2022][INFO] [SUB] D/GraalCompiled(22536): Caused by: java.lang.NoSuchMethodException: java.lang.Byte.valueOf(java.lang.String)
[Thu Aug 11 08:39:13 CEST 2022][INFO] [SUB] D/GraalCompiled(22536): at java.lang.Class.getMethod(DynamicHub.java:1114)
[Thu Aug 11 08:39:13 CEST 2022][INFO] [SUB] D/GraalCompiled(22536): at org.eclipse.jetty.util.TypeUtil.<clinit>(TypeUtil.java:147)
[Thu Aug 11 08:39:13 CEST 2022][INFO] [SUB] D/GraalCompiled(22536): ... 35 more
I've had lots of reflection problems, but this one i don't know how to tackle.
Here are the various parameters:
app compiled on linux (ubuntu)
netbeans 13
jdk 17.0.4
gluon plugin 2.8.4
graalvm-svm-java17-linux-gluon-22.0.0.3-Final
javaStaticSdkVersion='18-ea+prep18-8
galaxy tab A8, android 11
Don't know what else to say, i don't have a clue as to where to start, there are too many paths i can go and search.
Thanks for any input.
You're seeing this error because Jetty's TypeUtil class uses reflection for some String-to-basic type conversions.
Access via reflection is difficult to resolve upon compilation time, which is probably why your GraalVM native-image build fails: native-image only includes classes that are deemed necessary, and in this case it just missed to include it.
A proper fix would be to change TypeUtil to use method references instead of reflection (I ran into the same problem, and I've just filed Jetty pull request #9115).
However, you will most likely want to run your code now, and can't wait for this to be merged. Additionally, you may probably encounter more of these reflection issues even if this particular one is fixed.
In order for GraalVM native-image to know which classes and methods are accessed via reflection, you can specify them via configuration files in the resource classpath, under META-INF/native-image/com.yourdomain/your-project/reflect-config.json. Upon assembly, native-image will pick up this configuration from the classpath.
You can also use the GraalVM native-image Tracing Agent to create this file automatically.
To do this, invoke your app with the GraalVM JRE (i.e., using Hotspot, not native-image), and specify the following VM argument:
-agentlib:native-image-agent=config-output-dir=/tmp/native-image.{pid}
Interact with your app like you normally would (cover as much as possible), then terminate the VM.
You will see a bunch of JSON files created under /tmp/native-image.(PID). Copy all of them under the META-INF path described above and rebuild your native image.
For details see the GraalVM documentation, e.g., Reflection Use in Native Images
and Native Image Tracing Agent.
I am creating a swing based application in Java which uses some encryption technique. But
javax.crypto.KeyGenerator.getInstance("AES", "BC") gives exception:
java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
at javax.crypto.SunJCE_b.a(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
So what is the problem?
edit jre\lib\security\java.security
add security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider
copy bc*.jar to jre\lib\ext
To expand on the comment from GregS, all JCE provider JARs must be signed before they will be trusted by your Java runtime.
BouncyCastle dutifully supplies signed JARs that will work without a problem. However, if you extract class files from this JAR, or recompile the source, it will remove the signature and cause Java to reject the code.
See this related SO question: How to sign a custom JCE security provider
For those finding this issue but actually using SpongyCastle, it might be interesting to know that on Android there is no such signature test and for your tests you can use SpongyCastle via the openJDK-8 as that doesn't care about signatures neither.
For reference, with SpongyCastle the error reads:
java.lang.SecurityException: JCE cannot authenticate the provider SC
More information in this issue
We have been suffering with the same issue for a few weeks and had tried a lot of the suggested steps to no avail. Providing our solution below so others don't have to suffer like we did!
We were attempting to use bcprov-ext-jdk15on-162.jar, added to classpath, included in JBoss lib directories, bundled with WAR, marked as provided and added to JBoss /lib directories but no luck.
In the end, we tried different versions of bouncycastle and found a less recent version who's signature could be verified by our particular Java version's jarsigner (1.5X).
Despite the jar's signature being verifiable by our Java version, when the .jar is packaged into a WAR the signature was invalidated somehow by JBoss.
In the end, the solution for us was to;
1. Add bouncycastle jar to JBoss classpath
2. Add 'org.bouncycastle.jce.provider.BouncyCastleProvider' to 'java.security' providers
3. Mark bouncycastle in your WAR as a 'provided' dependency
Once we had a version of the .jar on our classpath and were sure that our WAR was not packaging it in we were golden.
The issue seems to be tightly coupled to whatever Java/JBoss version you happen to be using. So if this solution does not work for you I would suggest to test different versions of bouncycastle with
jarsigner -verify <bouncycastle.jar>
There are lot of solutions to this problem but unfortunately nobody talks about the causing issue.
If you are generating an executable jar that has BC.jar in it(in form of any dependency) than this issue would occur if below condition matches:
Generating jar via eclipse's export option i.e. Export-> Runnable Jar File -> Libary Handling {extract required libraries into generated Jar}-> FINISH
Boom, now you have landed into trouble and you will face an error i.e. JCE can't authenticate the provider BC
The reason for above problem is, when you create a jar with option 1 than you are actually unpacking the BouncyCastle jar again that violates the security assosiated with BC. So, whenever you run it again java validates it and finds current BC.jar in your assosiated jar has an error.
So, guys make sure what you are doing is justified because by changing the JDK's security data that will make it work but not for everyone.
How to make it work?{This will work on local/personal machine only,not on every machine }
edit jre\lib\security\java.security file
add security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider
copy bc*.jar to jre\lib\ext
That's it.
For me the issue was bcprov-ext-jdk16.jar was being discarded by sbt assembly.
[warn] Merging 'META-INF/license/LICENSE.bouncycastle.txt' with strategy 'discard'
..
[warn] Merging 'META-INF/maven/org.jasypt/jasypt/pom.properties' with strategy 'discard'
[warn] Merging 'META-INF/maven/org.jasypt/jasypt/pom.xml' with strategy 'discard'
..
So I ended up using the bouncycastle.jar from -classpath as below,
java -Denvironment=dev -cp chat-server.jar:/Users/prayagupd/.ivy2/cache/org.bouncycastle/bcprov-ext-jdk16/jars/bcprov-ext-jdk16-1.46.jar com.chat.server.ChatServer
What also works is putting the bouncycastle.jar to $JAVA_HOME/jre/lib/ext,
cp /Users/prayagupd/.ivy2/cache/org.bouncycastle/bcprov-ext-jdk16/jars/bcprov-ext-jdk16-1.46.jar $JAVA_HOME/jre/lib/ext/
$ ls -l $JAVA_HOME/jre/lib/ext/
total 55208
-rw-r--r-- 1 root wheel 1887089 May 7 21:22 bcprov-ext-jdk16-1.46.jar
-rw-rw-r-- 1 root wheel 3860502 Sep 5 2017 cldrdata.jar
-rw-rw-r-- 1 root wheel 8286 Sep 5 2017 dnsns.jar
-rw-rw-r-- 1 root wheel 44516 Sep 5 2017 jaccess.jar
-rwxrwxr-x 1 root wheel 18610276 Sep 5 2017 jfxrt.jar
-rw-rw-r-- 1 root wheel 1179093 Sep 5 2017 localedata.jar
-rw-rw-r-- 1 root wheel 1269 Sep 5 2017 meta-index
-rw-rw-r-- 1 root wheel 2022735 Sep 5 2017 nashorn.jar
-rw-rw-r-- 1 root wheel 41672 Sep 5 2017 sunec.jar
-rw-rw-r-- 1 root wheel 274148 Sep 5 2017 sunjce_provider.jar
-rw-rw-r-- 1 root wheel 248726 Sep 5 2017 sunpkcs11.jar
-rw-rw-r-- 1 root wheel 68924 Sep 5 2017 zipfs.jar
FYI: instead of modifying java.security and copying jar to \jre\lib\ext, below steps resolved my issue as well.
add Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider()) in your class.
add provided scope to bcprov.*.jar dependency in pom.xml.
put bcprov.*.jar to your specific folder(e.g: \lib), then refer it when run the project.
I was getting a NoSuchFileException when I was trying to access a file so I went through the usual process, checked the file existed, etc. I did this by checking the exception:
java.nio.file.NoSuchFileException: /var/config/file/test111.txt
then
vim /var/config/file/test111.txt
to verify the file actually existed. After some further testing I realized java couldn't see the /config folder.
File f = new File("/var");
f.list();
This returned some of the files and folders in /var, but not others, including /var/config. I did a ls -lah on the folder to check permissions and as far as I can tell there is no difference between what java can and can't see. For example it can see /var/cache
drwxr-xr-x 6 root root 4096 Feb 24 09:03 cache
drwxr-xr-x 3 root root 4096 Feb 24 09:04 config
Why would java be able to see some folders but not others when permissions are the same between folders?
Thanks!
I'm trying to run an example file that comes with ruby-processing, but it crashes with this error each time:
me$ rp5 run ~/rp_samples/samples/processing_app/library/movie/loop.rb
/Users/jimmy/rp_samples/samples/processing_app/library/movie/loop.rb:14 warning: ambiguous Java methods found, using background(int)
Java::JavaLang::UnsatisfiedLinkError
Could not load library: gstreamer
org.gstreamer.lowlevel.GstNative.load(org/gstreamer/lowlevel/GstNative.java:53)
org.gstreamer.lowlevel.GstNative.load(org/gstreamer/lowlevel/GstNative.java:43)
org.gstreamer.Gst.<clinit>(org/gstreamer/Gst.java:101)
java.lang.reflect.Constructor.newInstance(java/lang/reflect/Constructor.java:513)
RUBY.setup(/rp_samples/samples/processing_app/library/movie/loop.rb:16)
processing.core.PApplet.handleDraw(processing/core/PApplet.java:2361)
processing.core.PGraphicsJava2D.requestDraw(processing/core/PGraphicsJava2D.java:240)
processing.core.PApplet.run(processing/core/PApplet.java:2256)
java.lang.Thread.run(java/lang/Thread.java:695)
Here's what I've tried:
I was using the bundled (with ruby-processing) jruby-complete, but when this didn't work, I installed the regular jruby package.
I've already added the line from the answer on this page to resolve a Java::JavaLang::RuntimeException to get this far.
I found this question for java, but installing gstreamer via homebrew (on a Mac) didn't work and installing the universal pkg from gstreamer hasn't gotten me any further either.
I just want to play with ruby-processing :(. Let me know if I haven't given enough detail, but does anyone have any ideas? Thanks!
--
EDIT
I believe by looking at the gstreamer-java Google group, that the new version of gstreamer (> 1.0) isn't compatible. I found a collection of the old 0.10 gstreamer libs on homebrew and installed them.
I tried a 'sudo find / -iname "gstnative.java", and I can't seem to find the GSTNative.java file that this error is coming from. Maybe it's packaged somehow with ruby-processing? Anyway.. I found this line in gstreamer-java/src/org/gstreamer/lowlevel/Main.java:
System.setProperty("jna.library.path", "/usr/share/java:/opt/local/lib:/usr/local/lib:/usr/lib");
If I check for the files mentioned in the below comment (la /usr/local/lib/ | grep "gst"), I see them all and they're named both ways (0.10.0.dylib or 0.10.dylib). E.g.
lrwxr-xr-x 1 jimms admin 71 Jan 12 15:24 libgstinterfaces-0.10.0.dylib -> ../Cellar/gst-plugins-base010/0.10.36/lib/libgstinterfaces-0.10.0.dylib
lrwxr-xr-x 1 jimms admin 65 Jan 12 15:24 libgstinterfaces-0.10.a -> ../Cellar/gst-plugins-base010/0.10.36/lib/libgstinterfaces-0.10.a
lrwxr-xr-x 1 jimms admin 69 Jan 12 15:24 libgstinterfaces-0.10.dylib -> ../Cellar/gst-plugins-base010/0.10.36/lib/libgstinterfaces-0.10.dylib
So they seem to be there, but maybe I'm not understanding exactly what it's looking for. Any help is appreciated!
It's working now:
I'm not 100% sure about what fixed the problem finally, but, for future-googlers, here's a list of elements that seem to be required:
Do a brew search gst and install anything with 010 appended to it. Gstreamer-java has not been updated to be compatible with any version past gstreamer-0.10.
I updated my JDK to version 7 update 72 (maybe 8 will work, but I haven't tried). At this point, I removed the "java_args": "-d32" line from my .rp5rc file because 32bit mode wasn't supported.
The ruby-processing script doesn't seem to understand relative paths looks in a directory that's relative to where you run the rp5 command (instead of relative to the sketch itself) when loading a file with Movie.new, and so I changed it to an absolute path and Eureka!
--
Edit
Edited step 3 above for clarity: If I had cded into ~/rp_samples/samples/processing_app/library/movie/ before running rp5 run loop.rb it would have helped the troubleshooting process.
I have created a java application and deploying it using java web start.Application is working fine till JDK 7u21. But after that I updated my jdk version to 7u45.Application is blocked due after throwing security exception of self signed.
After that I explore issue on different website they suggested to lower down the security level in Java Control Panel.But I don't like this solution as I don't want a work around but a complete solution.
After more exploration I found following method of adding following attribute to MANIFEST.MF
Application-Name: My App Name
Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Trusted-Library: true
I have added all this using following command
jar uvmf abc.jar patch.txt
where patch.txt contains above attribute that I have to add to manifest.MF
As my application contains some of eclipse plugins so I deleted ECLIPSEF.SF and ECLIPSEF.RSA files and again signed all plugins using my certificate.
But still I didn't get rid of error.I am getting following errors :
basic: Your security settings have blocked a self-signed application from running with an out-of-date or expired version of Java.
security: Trust for: http://192.15.23.6:8888/myapps/plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503.jar has ended: Thu Jan 01 05:30:00 IST 1970
Please suggest how to explore it at next step to remove errors.
I have found solution to my above problem by signing JNLP
refer to following thread
https://community.oracle.com/thread/2593583?start=15&tstart=0
Now I have to do this for dynamic jnlp. A solution is already provided in this thread but I am not able to understand that how that happened and how to implement that solution.
Please guide.