I saw this error while the ant task is repacking the JARs, it seems to
ignore the error and proceed though:
repack-libs:
[echo] Repacking libs in web-start/../release/web-start
[apply] Exception in thread "main" java.lang.SecurityException:
invalid SHA1 signature file digest for
org/bouncycastle/jcajce/provider/digest/Whirlpool$Digest.class
[apply] at
sun.security.util.SignatureFileVerifier.verifySection(SignatureFileVerifier.java:441)
[apply] at
sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:231)
[apply] at
sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
[apply] at
java.util.jar.JarVerifier.processEntry(JarVerifier.java:288)
[apply] at java.util.jar.JarVerifier.update(JarVerifier.java:199)
[apply] at
java.util.jar.JarFile.initializeVerifier(JarFile.java:323)
[apply] at java.util.jar.JarFile.getInputStream(JarFile.java:388)
[apply] at
com.sun.java.util.jar.pack.PackerImpl$DoPack$InFile.getInputStream(PackerImpl.java:373)
[apply] at
com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:459)
[apply] at
com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73)
[apply] at com.sun.java.util.jar.pack.Driver.main(Driver.java:259)
[apply] Result: 1
When we originally created the webstart, the full BouncyCastle-jar was not
yet part of Jitsi. Either exclude it from recompression altogether or try
with segment-limit as indicated in the BouncyCastle FAQ
(http://goo.gl/t5gmU1).
Ingo
···
-----Original Message-----
From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of
Daniel Pocock
Sent: Donnerstag, 10. Juli 2014 22:31
To: 'Jitsi Developers'
Subject: [jitsi-dev] error repacking BouncyCastle
I saw this error while the ant task is repacking the JARs, it seems to
ignore the error and proceed though:
repack-libs:
[echo] Repacking libs in web-start/../release/web-start
[apply] Exception in thread "main" java.lang.SecurityException:
invalid SHA1 signature file digest for
org/bouncycastle/jcajce/provider/digest/Whirlpool$Digest.class
[apply] at
sun.security.util.SignatureFileVerifier.verifySection(SignatureFileVerifier.
java:441)
[apply] at
sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.ja
va:231)
[apply] at
sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:1
76)
[apply] at
java.util.jar.JarVerifier.processEntry(JarVerifier.java:288)
[apply] at java.util.jar.JarVerifier.update(JarVerifier.java:199)
[apply] at
java.util.jar.JarFile.initializeVerifier(JarFile.java:323)
[apply] at java.util.jar.JarFile.getInputStream(JarFile.java:388)
[apply] at
com.sun.java.util.jar.pack.PackerImpl$DoPack$InFile.getInputStream(PackerImp
l.java:373)
[apply] at
com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:459)
[apply] at
com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73)
[apply] at com.sun.java.util.jar.pack.Driver.main(Driver.java:259)
[apply] Result: 1
Apparently, if it is already signed (which it is, unlike most of the
other JARs) the jarsigner fails to correctly sign it using the
certificate being used for signing the JNLP
In fact, I found the following:
- jarsign adds an SHA-256 signature using my certificate
- but the JAR still contains the SHA-1 signatures as well, signed by
BC's certificate
When validating, it is trying to use my certificate to validate the
SHA-1 signature and that fails.
I worked around this by stripping out the signatures completely:
- remove META-INF/BC*
- remove the signature lines from the manifest
- zip the JAR again
I had also tried doing both SHA-1 and SHA-256 signatures in the
WebStartBuild.xml:
but that doesn't seem to be enough to make it work.
···
On 10/07/14 18:46, Ingo Bauersachs wrote:
When we originally created the webstart, the full BouncyCastle-jar was not
yet part of Jitsi. Either exclude it from recompression altogether or try
with segment-limit as indicated in the BouncyCastle FAQ
(http://goo.gl/t5gmU1).
The BC jar is signed so that it can be loaded as a Java security provider. As it is signed, why do you want to repack/resign it at all? As far as I remember, it is not required that all webstart signatures are from the same certificate - although this might have changed since 1.6.24, the last version we were using.
The SHA256 sigs also seem to be something introduced with newer Java versions. Have you tried using SHA1 exclusively?
Freundliche Grüsse,
Ingo Bauersachs
-- sent from my mobile
···
Le 09.08.2014 à 23:37, "Daniel Pocock" <daniel@pocock.pro> a écrit :
On 10/07/14 18:46, Ingo Bauersachs wrote:
When we originally created the webstart, the full BouncyCastle-jar was not
yet part of Jitsi. Either exclude it from recompression altogether or try
with segment-limit as indicated in the BouncyCastle FAQ
(http://goo.gl/t5gmU1).
It is more annoying than that
Apparently, if it is already signed (which it is, unlike most of the
other JARs) the jarsigner fails to correctly sign it using the
certificate being used for signing the JNLP
In fact, I found the following:
- jarsign adds an SHA-256 signature using my certificate
- but the JAR still contains the SHA-1 signatures as well, signed by
BC's certificate
When validating, it is trying to use my certificate to validate the
SHA-1 signature and that fails.
I worked around this by stripping out the signatures completely:
- remove META-INF/BC*
- remove the signature lines from the manifest
- zip the JAR again
I had also tried doing both SHA-1 and SHA-256 signatures in the
WebStartBuild.xml:
The BC jar is signed so that it can be loaded as a Java security provider. As it is signed, why do you want to repack/resign it at all? As far as I remember, it is not required that all webstart signatures are from the same certificate - although this might have changed since 1.6.24, the last version we were using.
Yes, newer JDKs expect all the WebStart JARs to be signed by the same
certificate.
The SHA256 sigs also seem to be something introduced with newer Java versions. Have you tried using SHA1 exclusively?
Yes, 1.7 does SHA256 by default
In the build.xml, we can explicitly tell jarsign to use a specific hash
In fact, a JAR can be signed with both SHA1 and SHA256 - this just means
repeating the jarsign twice in build.xml - it is in the pull request for
my web-start branch