4

In my scala project I use "org.bouncycastle" % "bcprov-jdk14" % "1.51" for cryptography.
If it test my project in Scala IDE it works fine. But once I make a JAR and try to run it via java -jar ... it throws an exception: Exception in thread "main" java.lang.SecurityException: JCE cannot authenticate the provider BC

I use https://github.com/sbt/sbt-assembly for making a JAR and here's my java -version output: 

java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) Server VM (build 24.72-b04, mixed mode)

When making a JAR I see this output: 

[info] Merging files...
[warn] Merging 'META-INF/BCKEY.DSA' with strategy 'discard'
[warn] Merging 'META-INF/BCKEY.SF' with strategy 'discard'
[warn] Merging 'META-INF/LAMBDAWO.SF' with strategy 'discard'
[warn] Merging 'META-INF/MANIFEST.MF' with strategy 'discard'
[warn] Merging 'reference.conf' with strategy 'concat'
[warn] Merging 'rootdoc.txt' with strategy 'concat'
[warn] Strategy 'concat' was applied to 2 files
[warn] Strategy 'discard' was applied to 4 files

How can I fix this issue?

src091
  • 2,807
  • 7
  • 44
  • 74
  • 1
    Check that sbt-assembly is not including digital signature files in the generated jar (in META-INF/), as they'll become invalid with the jar changes, so you need to exclude them. Or you may need to find a way to load bcprov from its "real" jar as that jar is signed. – lmm Nov 27 '14 at 12:00
  • @lmm how do I exclude META-INF/ files? Also, I've updated my post with some relevant (as I suppose) assembly output. Perhaps it'll further clarify what's going on. – src091 Nov 27 '14 at 12:10
  • 1
    It looks like the signatures were discarded, which is better than including them but leaving them invalid. To me that suggests that you need a valid signature, which is confirmed by e.g. http://stackoverflow.com/questions/13721579/jce-cannot-authenticate-the-provider-bc-in-java-swing-application. So you can't use sbt-assembly with bcprov; you'll have to find a way to use the unmodified bcprov jars. – lmm Nov 27 '14 at 12:13
  • @lmm thanks, I've found a solution in a thread you've provided, namely this comment: http://stackoverflow.com/a/19562164/179746. Strangely enough, it was down voted for some reason. Perhaps it's a bad practice or something? – src091 Nov 27 '14 at 13:04
  • 2
    I think it's more that it's less practical for many deployment models as you have to modify the JRE itself. – lmm Nov 27 '14 at 13:49

0 Answers0