Thanks to David and Jesse for the quick responses. @David:There is no Java 7 involved, and, although there is a nested jar, the class that is receiving the incorrect signature is not contained in the nested jar. The "eclipse.inf" file was an excellent suggestion that hadn't even occurred to me. I've added the file, and the build now produces a valid, usable p2 repo with signed content. I guess it was just one of those pack200 problems, although it had worked in the past. I'm satisfied with a working p2 repo with one non-packed jar, so I won't be pursuing the issue any further.
@Jesse:It doesn't look like this has anything to do with the eclipse-maven-signing-plugin, and other than this pack200 problem the plugin has simplified our previous process quite a bit. Thanks for that.
- Zeb On 29.02.2012 16:34, David M Williams wrote:
Does it have nested jars? And is Java 1.7 involved? If so, you might read through https://bugs.eclipse.org/bugs/show_bug.cgi?id=361628 But, other than that, I think many projects have occasionally found issues where some jars simply can not be "packed200'd" correctly and for those cases must be excluded from packing, via properties in eclipse.inf file, such as jarprocessor.exclude.pack=true jarprocessor.exclude.children=true This allows the jars to still be signed ... they are simply not compressed with pack200. One bug that documents such a case is https://bugs.eclipse.org/bugs/show_bug.cgi?id=335806 There are various VM bugs opened against pack200 for problem cases, but as far as I can tell, there's not much rhyme or reason for which cases cause problems. And, not sure how any of these would be related to the "eclipse-signing-maven-plugin"? So, perhaps a coincidental timing? Hope this info helps a little ... keep us posted if you find anything. From: Zeb Ford-Reitz<[email protected]> To: [email protected], Date: 02/29/2012 10:20 AM Subject: [cross-project-issues-dev] Jubula: Invalid signature with eclipse-signing-maven-plugin Sent by: [email protected] We recently made the switch over to the eclipse-signing-maven-plugin for repacking, signing, and packing the Jubula project, using https://hudson.eclipse.org/hudson/job/linuxtools-Indigo as a reference (for job and pom). After the switch, I noticed that the produced p2 repository contained at least one invalidly signed jar (org.eclipse.jubula.client.core). The jar in question contains classes compiled from generated code, but other than that, I'm not sure what would cause this jar to be handled any differently from the others. In the job https://hudson.eclipse.org/hudson/job/jubula-nightly, the following error occurs while performing the pack/repack operation after conditioning and signing: ---------------------------------------------- Processing /opt/users/hudsonbuild/workspace/jubula-nightly/jubula/org.eclipse.jubula.site/target/signed/site_assembly.zip [ERROR] STDERR: Exception in thread "main" java.lang.SecurityException: SHA1 digest error for org/eclipse/jubula/client/core/gen/parser/parameter/parser/Parser.class STDERR: at sun.security.util.ManifestEntryVerifier.verify (ManifestEntryVerifier.java:196) STDERR: at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201) STDERR: at java.util.jar.JarVerifier.update(JarVerifier.java:188) STDERR: at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:403) STDERR: at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) STDERR: at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) STDERR: at java.io.BufferedInputStream.read(BufferedInputStream.java:313) STDERR: at java.io.FilterInputStream.read(FilterInputStream.java:111) STDERR: at com.sun.java.util.jar.pack.ClassReader$1.read(ClassReader.java:38) STDERR: at java.io.DataInputStream.readFully(DataInputStream.java:176) STDERR: at java.io.DataInputStream.readFully(DataInputStream.java:152) STDERR: at com.sun.java.util.jar.pack.ClassReader.readAttributes(ClassReader.java:401) STDERR: at com.sun.java.util.jar.pack.ClassReader.readCode(ClassReader.java:423) STDERR: at com.sun.java.util.jar.pack.ClassReader.readAttributes(ClassReader.java:392) STDERR: at com.sun.java.util.jar.pack.ClassReader.readMember(ClassReader.java:314) STDERR: at com.sun.java.util.jar.pack.ClassReader.readMembers(ClassReader.java:300) STDERR: at com.sun.java.util.jar.pack.ClassReader.read(ClassReader.java:126) STDERR: at com.sun.java.util.jar.pack.PackerImpl$DoPack.readClass(PackerImpl.java:491) STDERR: at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:465) STDERR: at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73) STDERR: at com.sun.java.util.jar.pack.Driver.main(Driver.java:262) ---------------------------------------------- The job succeeds despite that error, but running "jarsigner -verify org.eclipse.jubula.client.core_$VERSION.jar" on the resulting repo produces the same error. Has anybody encountered a similar error or could offer some advice? - Zeb -- BREDEX GmbH Mauernstr. 33 38100 Braunschweig Tel.: +49-531-24330-0 Fax: +49-531-24330-99 http: www.bredex.de Geschäftsführer: Hans-J. Brede, Achim Lörke, Ulrich Obst Amtsgericht Braunschweig HRB 2450 [attachment "smime.p7s" deleted by David M Williams/Raleigh/IBM] _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-- BREDEX GmbH Mauernstr. 33 38100 Braunschweig Tel.: +49-531-24330-0 Fax: +49-531-24330-99 http: www.bredex.de Geschäftsführer: Hans-J. Brede, Achim Lörke, Ulrich Obst Amtsgericht Braunschweig HRB 2450
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
