Since a few days we see a similar problem with signing/packing the JGit/EGit build [1], this used to work until the weekend. No idea what happened to make it fail.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=372845 extract from this bug: There is currently a problem with the signing plugin, it throws a SecurityException "SHA1 digest error". No clue yet why. I retried doing a clean fresh build for both JGit and EGit by wiping their Hudson workspaces and rebuilding both on Hudson but this didn't fix the problem. Processing /opt/public/jobs/egit/workspace/org.eclipse.egit-updatesite/target/signed/site_assembly.zip [ERROR] STDERR: Exception in thread "main" java.lang.SecurityException: SHA1 digest error for org/eclipse/jgit/blame/BlameGenerator.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.read(BufferedInputStream.java:235) STDERR: at java.io.FilterInputStream.read(FilterInputStream.java:66) STDERR: at com.sun.java.util.jar.pack.ClassReader$1.read(ClassReader.java:43) STDERR: at java.io.DataInputStream.readInt(DataInputStream.java:354) STDERR: at com.sun.java.util.jar.pack.ClassReader.readInt(ClassReader.java:79) STDERR: at com.sun.java.util.jar.pack.ClassReader.readAttributes(ClassReader.java:324) 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) 2012/3/1 Zeb Ford-Reitz <[email protected]> > 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<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<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<Zeb.Ford-Reitz@**bredex.de<[email protected]> >> > >> To: >> cross-project-issues-dev@**eclipse.org<[email protected]> >> , >> Date: 02/29/2012 10:20 AM >> Subject: [cross-project-issues-dev] Jubula: Invalid signature with >> eclipse-signing-maven-plugin >> Sent by: >> cross-project-issues-dev-**[email protected]<[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<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<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 >> cross-project-issues-dev@**eclipse.org<[email protected]> >> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >> >> >> ______________________________**_________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@**eclipse.org<[email protected]> >> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<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 > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- Matthias
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
