Re: [pde-build-dev] Strange error when doing pack200 normalization on Wi

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Andrew,
you nailed this one right away. I was using Eclipse 3.2.2. Thanks for 
the info, problem solved.

Just out of curiosity, even if the normalize process adds an extraneous 
CR to the file, why does that matter? Why isn't the signer simply using 
the bytes it finds for the SHA1 calculation?

Regards,
Thomas Hallgren

Andrew Niefer wrote:
> Thomas,
> What version of the jarprocessor are you using?  There was a bug 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=163421 fixed in M6 that 
> would cause the difference in the line endings.
> I expect that the signer is just taking a hash of the file contents, 
> so yes a change in line endings will cause it to fail verification.
>
> -Andrew
>
>
>
> *Thomas Hallgren <thomas@xxxxxxx>*
> Sent by: pde-build-dev-bounces@xxxxxxxxxxx
>
> 05/14/2007 08:21 AM
> Please respond to
> "Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>
>
>
> 	
> To
> 	"Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>
> cc
> 	
> Subject
> 	[pde-build-dev] Strange error when doing pack200 normalization on     
>    Windows
>
>
>
> 	
>
>
>
>
>
> Hi,
> I have a scenario where I build all of Buckminster on my local machine.
> Well almost, the signing part is of course done at Eclipse.org. Here's
> what I do.
>
> 1. Build a zip file consisting of all features and plugins that I want
> to publish.
> 2. Run the jarprocessor to normalize all jars in this zip.
> 3. Send the zip to Eclipse for signing.
> 4. Wait for signing to complete.
> 5. Obtain the signed zip from Eclipse.org and run the jarprocessor to
> pack it.
>
> On my Windows box, the last step just hangs. I've debugged it to a place
> where pack200 is invoked. If I invoke pack200 from the command line
> using the same arguments, it prints the following exception trace and 
> dies:
>
> Exception in thread "main" java.lang.SecurityException: SHA1 digest
> error for META-INF/eclipse.inf
>        at
> sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:196)
>        at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201)
>        at java.util.jar.JarVerifier.update(JarVerifier.java:188)
>        at
> java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:403)
>        at java.io.InputStream.read(InputStream.java:89)
>        at
> com.sun.java.util.jar.pack.Package$File.readFrom(Package.java:771)
>        at
> com.sun.java.util.jar.pack.PackerImpl$DoPack.readFile(PackerImpl.java:511)
>        at
> com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:472)
>        at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73)
>        at com.sun.java.util.jar.pack.Driver.main(Driver.java:262)
>
> Looking at the culprit META-INF/eclipse.inf file, I can conclude that it
> indeed should have another SHA1 signature then the one listed in
> META-INF/Eclipse.sf. When I analyze the file (using od -c ;-) ) I can
> conclude that it contains one line that ends with CR-NL and another that
> ends with NL. This made me suspicious so instead of running my build on
> a Windows machine, I tried it on a Linux box. There, it works like a 
> charm.
>
> So my question is, is the signer sensitive to the types of newlines that
> are used? If so, why is that? Is it just this one file or does it
> convert other files as well (if that is whats happening)?
>
> Regards,
> Thomas Hallgren
>
> _______________________________________________
> pde-build-dev mailing list
> pde-build-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pde-build-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pde-build-dev mailing list
> pde-build-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pde-build-dev
>