Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Jubula: Invalid signature with eclipse-signing-maven-plugin

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 <Zeb.Ford-Reitz@xxxxxxxxx>
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<Zeb.Ford-Reitz@bredex.de>
To:     cross-project-issues-dev@eclipse.org,
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-bounces@xxxxxxxxxxx



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
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




--
Matthias

Back to the top