While troubleshooting some cryptographic code, I saw a strange hierarchy of stacktraces. I've solved the orignal problem, but became curious about how a stacktrace like this could be generated. Can anyone enlighten me?
Please note that I can't copy-paste the stacktrace verbatim. I must elide frames that can expose proprietary code.
businesscode.BusinessException: Failed while generating session key
at businesscode.businessthing.BusinessMethod(BusinessApp.java:NN)
... NN more
Caused by: java.security.NoSuchProviderException: JCE cannot authenticate the provider XXX
at javax.crypto.SunJCE_b.a(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
at businesslib.generateKey(BusinessLib.java:NN)
... NN more
Caused by: javax.util.jar.JarException: Cannot parse X.jar
at javax.crypto.SunJCE_c.a(DashoA13*..)
at javax.crypto.SunJCE_b.b(DashoA13*..)
at javax.crypto.SunJCE_b.a(DashoA13*..)
... 25 more
Why method names like a and b (SunJCE_c.a, SunJCE_b.b) and file/line information as DashoA13*?
Oracle Java 6 32-bit, running on 64-bit Linux and 32-bit Windows.
Could this be because some information is unavailable, perhaps due to runtime optimizations? Or some willful obfuscation? JNI?
The issue that caused this was that a third-party crypto provider was packaged incorrectly in a jar file.
EDIT: The original issue (NoSuchProviderException: JCE cannot authenticate the provider...
) was caused by a naive build process that extracted the crypto provider classes from their original jar and repackaged them in a new, pristine jar - but without the required signature information.
Thanks to Siva and owlstead for reminding me of signed jars :)
There are a few options here (and I'm assuming that before this the signature did verify):
.jar
was removed or the contents / signature were altered.As for the weird names; those names are names of classes that have been obfuscated with a code obfuscator. The are not part of the public API, so there is no reason for you to know the contents. They contain the code to verify the signature and are therefore security relevant.