Dear ODK developers,
I cloned the ODK Briefcase sources as of April 29, then built a custom .jar
based on those sources. When I try to decrypt a certain form with my jar, I
get:
Error decrypting submission uuid49b0e981-9a17-4a19-80f4-de651129205d Cause:
org.opendatakit.briefcase.model.CryptoException: Error decrypting
base64EncryptedKey Cause: java.security.NoSuchAlgorithmException: Cannot
find any provider supporting RSA/NONE/OAEPWithSHA256AndMGF1Padding
However, if I decrypt the very same form using the production Briefcase
v1.0.2.1 .jar (using the same private key and the same local form
definition and data), it works just fine. Seeing as I think that I'm
building from the actual v1.0.2.1 sources, clearly there's something wrong
with my build procedure. However, when building the cloned project and
exporting the runnable .jar I got no errors.
Any ideas?
Thanks!
Chris
Did you install the JCE Unlimited Strength encryption policy files?
Available here (at the bottom of the page):
http://www.oracle.com/technetwork/java/javase/downloads/index.html
What Java are you using (Oracle/Sun, or Open JDK?). We develop with
Oracle/Sun.
Mitch
···
On Thu, May 3, 2012 at 7:35 AM, Christopher Robert wrote:
Dear ODK developers,
I cloned the ODK Briefcase sources as of April 29, then built a custom
.jar based on those sources. When I try to decrypt a certain form with my
jar, I get:
Error decrypting submission uuid49b0e981-9a17-4a19-80f4-de651129205d
Cause: org.opendatakit.briefcase.model.CryptoException: Error decrypting
base64EncryptedKey Cause: java.security.NoSuchAlgorithmException: Cannot
find any provider supporting RSA/NONE/OAEPWithSHA256AndMGF1Padding
However, if I decrypt the very same form using the production Briefcase
v1.0.2.1 .jar (using the same private key and the same local form
definition and data), it works just fine. Seeing as I think that I'm
building from the actual v1.0.2.1 sources, clearly there's something wrong
with my build procedure. However, when building the cloned project and
exporting the runnable .jar I got no errors.
Any ideas?
Thanks!
Chris
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Hi Mitch,
Thanks, as always, for the quick reply.
I'm on OSX and my Java run-time is:
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
I figure that this JRE must be fine since I can decrypt fine using the
Briefcase production build (whereas on my Windows VM I had to, as you
suggest, install the unlimited-strength encryption files).
As for Eclipse, it apparently compiles by itself and its settings are for
compliance to Java v1.6. It must be a matter of the libs it's linking in.
Looks like everything that doesn't come from the Briefcase repository is
coming from the "JRE System Library [JavaSE-1.6]".
Specifically, /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar.
Also
in /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security
were some of those policy files -- so I updated those with the
unlimited-strength versions just in case. It didn't make a difference.
What did make a difference, in the end, was how I exported the runnable
.jar: selecting "Library handling: Extract required libraries into
generated JAR" yields the runtime exception, whereas selecting "Library
handling: Package required libraries into generated JAR" yields a JAR that
decrypts fine. Go figure. My impression had been that these two options
included the same stuff in the JAR, just packaged differently. But here's a
theory: when packaging JARs inside the JAR, perhaps some (JCE?) classes get
picked up from the run-time JRE environment rather than fishing them out of
the JARs-in-JARs -- while directly-packaged class files within the JAR take
precedence over run-time JRE versions? If this were correct, that would
mean that my JRE has a provider that my JDK doesn't, and so I actually want
the JRE's provider to take precedence.
If I'm right about that -- and possibly even if I'm not -- then there may
be lurking compatibility issues here. For instance, if my JDK doesn't have
the necessary provider, then ODK users' JRE's might not either. Is the
current method of building and packaging Briefcase the most-compatible
method? If you want me to help test variations or otherwise help dig deeper
into this, please just let me know. Otherwise, at least for now, I'll just
be careful to package JARs-in-JARs.
Thanks,
Chris
···
On Thursday, May 3, 2012, Mitch S wrote:
Did you install the JCE Unlimited Strength encryption policy files?
Available here (at the bottom of the page):
http://www.oracle.com/technetwork/java/javase/downloads/index.html
What Java are you using (Oracle/Sun, or Open JDK?). We develop with
Oracle/Sun.
Mitch
On Thu, May 3, 2012 at 7:35 AM, Christopher Robert <chrislrobert@gmail.com<javascript:_e({}, 'cvml', 'chrislrobert@gmail.com');> wrote:
Dear ODK developers,
I cloned the ODK Briefcase sources as of April 29, then built a custom
.jar based on those sources. When I try to decrypt a certain form with my
jar, I get:
Error decrypting submission uuid49b0e981-9a17-4a19-80f4-de651129205d
Cause: org.opendatakit.briefcase.model.CryptoException: Error decrypting
base64EncryptedKey Cause: java.security.NoSuchAlgorithmException: Cannot
find any provider supporting RSA/NONE/OAEPWithSHA256AndMGF1Padding
However, if I decrypt the very same form using the production Briefcase
v1.0.2.1 .jar (using the same private key and the same local form
definition and data), it works just fine. Seeing as I think that I'm
building from the actual v1.0.2.1 sources, clearly there's something wrong
with my build procedure. However, when building the cloned project and
exporting the runnable .jar I got no errors.
Any ideas?
Thanks!
Chris
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com <javascript:_e({}, 'cvml',
'mitchellsundt@gmail.com');>
Ah, yes. There is a lot of dynamic class loading going on. If you only
package the classes that can be identified through static (compile-time)
analysis, you will be omitting the algorithm-implementation classes that
the cryptography libraries contain. Or, it may be that the cryptography
code performs runtime checks to confirm that it is running within a signed
jar.
Thanks for sleuthing this out. I've updated the wiki with this
information: http://code.google.com/p/opendatakit/wiki/ODKBriefcase
Mitch
···
On Thu, May 3, 2012 at 12:05 PM, Christopher Robert wrote:
Hi Mitch,
Thanks, as always, for the quick reply.
I'm on OSX and my Java run-time is:
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
I figure that this JRE must be fine since I can decrypt fine using the
Briefcase production build (whereas on my Windows VM I had to, as you
suggest, install the unlimited-strength encryption files).
As for Eclipse, it apparently compiles by itself and its settings are for
compliance to Java v1.6. It must be a matter of the libs it's linking in.
Looks like everything that doesn't come from the Briefcase repository is
coming from the "JRE System Library [JavaSE-1.6]".
Specifically, /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar.
Also
in /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security
were some of those policy files -- so I updated those with the
unlimited-strength versions just in case. It didn't make a difference.
What did make a difference, in the end, was how I exported the runnable
.jar: selecting "Library handling: Extract required libraries into
generated JAR" yields the runtime exception, whereas selecting "Library
handling: Package required libraries into generated JAR" yields a JAR that
decrypts fine. Go figure. My impression had been that these two options
included the same stuff in the JAR, just packaged differently. But here's a
theory: when packaging JARs inside the JAR, perhaps some (JCE?) classes get
picked up from the run-time JRE environment rather than fishing them out of
the JARs-in-JARs -- while directly-packaged class files within the JAR take
precedence over run-time JRE versions? If this were correct, that would
mean that my JRE has a provider that my JDK doesn't, and so I actually want
the JRE's provider to take precedence.
If I'm right about that -- and possibly even if I'm not -- then there may
be lurking compatibility issues here. For instance, if my JDK doesn't have
the necessary provider, then ODK users' JRE's might not either. Is the
current method of building and packaging Briefcase the most-compatible
method? If you want me to help test variations or otherwise help dig deeper
into this, please just let me know. Otherwise, at least for now, I'll just
be careful to package JARs-in-JARs.
Thanks,
Chris
On Thursday, May 3, 2012, Mitch S wrote:
Did you install the JCE Unlimited Strength encryption policy files?
Available here (at the bottom of the page):
http://www.oracle.com/technetwork/java/javase/downloads/index.html
What Java are you using (Oracle/Sun, or Open JDK?). We develop with
Oracle/Sun.
Mitch
On Thu, May 3, 2012 at 7:35 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Dear ODK developers,
I cloned the ODK Briefcase sources as of April 29, then built a custom
.jar based on those sources. When I try to decrypt a certain form with my
jar, I get:
Error decrypting submission uuid49b0e981-9a17-4a19-80f4-de651129205d
Cause: org.opendatakit.briefcase.model.CryptoException: Error decrypting
base64EncryptedKey Cause: java.security.NoSuchAlgorithmException: Cannot
find any provider supporting RSA/NONE/OAEPWithSHA256AndMGF1Padding
However, if I decrypt the very same form using the production Briefcase
v1.0.2.1 .jar (using the same private key and the same local form
definition and data), it works just fine. Seeing as I think that I'm
building from the actual v1.0.2.1 sources, clearly there's something wrong
with my build procedure. However, when building the cloned project and
exporting the runnable .jar I got no errors.
Any ideas?
Thanks!
Chris
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
And it isn't anything to worry about.
Packaging the jars within the runnable jar is the safe way to do it.
Extracting the jars into the runnable jar is an optimization for class
loading that obviously has limitations.
The search order for jars will always be to search first in the runnable
jar, then in your primary Java installation. The code has no dependencies
on the JDK, just standard JRE libraries that are required to be present in
all compliant implementations. The runnable jar is portable and not
dependent upon any structures on your computer as long as the
META-INF\MANIFEST.MF doesn't have any hard-coded paths except ".", which it
doesn't.
Mitch
···
On Thu, May 3, 2012 at 2:06 PM, Mitch S wrote:
Ah, yes. There is a lot of dynamic class loading going on. If you only
package the classes that can be identified through static (compile-time)
analysis, you will be omitting the algorithm-implementation classes that
the cryptography libraries contain. Or, it may be that the cryptography
code performs runtime checks to confirm that it is running within a signed
jar.
Thanks for sleuthing this out. I've updated the wiki with this
information: http://code.google.com/p/opendatakit/wiki/ODKBriefcase
Mitch
On Thu, May 3, 2012 at 12:05 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Mitch,
Thanks, as always, for the quick reply.
I'm on OSX and my Java run-time is:
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
I figure that this JRE must be fine since I can decrypt fine using the
Briefcase production build (whereas on my Windows VM I had to, as you
suggest, install the unlimited-strength encryption files).
As for Eclipse, it apparently compiles by itself and its settings are for
compliance to Java v1.6. It must be a matter of the libs it's linking in.
Looks like everything that doesn't come from the Briefcase repository is
coming from the "JRE System Library [JavaSE-1.6]".
Specifically, /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar.
Also
in /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security
were some of those policy files -- so I updated those with the
unlimited-strength versions just in case. It didn't make a difference.
What did make a difference, in the end, was how I exported the runnable
.jar: selecting "Library handling: Extract required libraries into
generated JAR" yields the runtime exception, whereas selecting "Library
handling: Package required libraries into generated JAR" yields a JAR that
decrypts fine. Go figure. My impression had been that these two options
included the same stuff in the JAR, just packaged differently. But here's a
theory: when packaging JARs inside the JAR, perhaps some (JCE?) classes get
picked up from the run-time JRE environment rather than fishing them out of
the JARs-in-JARs -- while directly-packaged class files within the JAR take
precedence over run-time JRE versions? If this were correct, that would
mean that my JRE has a provider that my JDK doesn't, and so I actually want
the JRE's provider to take precedence.
If I'm right about that -- and possibly even if I'm not -- then there may
be lurking compatibility issues here. For instance, if my JDK doesn't have
the necessary provider, then ODK users' JRE's might not either. Is the
current method of building and packaging Briefcase the most-compatible
method? If you want me to help test variations or otherwise help dig deeper
into this, please just let me know. Otherwise, at least for now, I'll just
be careful to package JARs-in-JARs.
Thanks,
Chris
On Thursday, May 3, 2012, Mitch S wrote:
Did you install the JCE Unlimited Strength encryption policy files?
Available here (at the bottom of the page):
http://www.oracle.com/technetwork/java/javase/downloads/index.html
What Java are you using (Oracle/Sun, or Open JDK?). We develop with
Oracle/Sun.
Mitch
On Thu, May 3, 2012 at 7:35 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Dear ODK developers,
I cloned the ODK Briefcase sources as of April 29, then built a custom
.jar based on those sources. When I try to decrypt a certain form with my
jar, I get:
Error decrypting submission uuid49b0e981-9a17-4a19-80f4-de651129205d
Cause: org.opendatakit.briefcase.model.CryptoException: Error decrypting
base64EncryptedKey Cause: java.security.NoSuchAlgorithmException: Cannot
find any provider supporting RSA/NONE/OAEPWithSHA256AndMGF1Padding
However, if I decrypt the very same form using the production Briefcase
v1.0.2.1 .jar (using the same private key and the same local form
definition and data), it works just fine. Seeing as I think that I'm
building from the actual v1.0.2.1 sources, clearly there's something wrong
with my build procedure. However, when building the cloned project and
exporting the runnable .jar I got no errors.
Any ideas?
Thanks!
Chris
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com