[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Galileo mirroring problem. Need help!

> The file was reconditioned with a Java 1.5 Pack200, and then signed at 
Eclipse.org, and then packed again with a Java 1.5 Pack200.

That is a little different than the flow many of us use. Since the 
Eclipse.org script also does a re-pack (conditioning) many of us do not do 
that before submitting to be signed. While this shouldn't be a problem (to 
-repack twice) it might expose some other bug the rest of us do not see. 

BUT, you say you can 'manually' unpack and verify the pack.gz file, so I 
think it must be more than that. 

> Any ideas are greatly appreciated. I'm starting to drain out of them.

Ok, you asked, so if it is any ideas you want, here's some more wild ones. 
I hate to suggest this to _you_ ... but are you sure the files the build 
is "getting" are really in the same repo as the ones you are checking 
(i.e. urls in artifacts.xml/jar are correct?  Also ... since this seems to 
happen for buckminser, and buckminster is currently installed in the 
Platform that is running the build, any chance that is causing some 
mix-up? We seemed, for a while, to see issues when the "legacy update 
site" support was being used for one site, where the whole site was 
downloaded and meta data was being re-generated ... any chance similar 
issues are coming into play here? I know you don't specify a 'site.xml' in 
your url ... but, if there is a local, installed version available also 
then maybe ... I don't know, sounds crazy. 






From:
Thomas Hallgren <thomas@xxxxxxx>
To:
P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:
05/08/2009 12:20 PM
Subject:
Re: [p2-dev] Galileo mirroring problem. Need help!
Sent by:
p2-dev-bounces@xxxxxxxxxxx



Andrew Niefer wrote: 

Could the pack.gz file hav been created with Java 1.6? 
The file was reconditioned with a Java 1.5 Pack200, and then signed at 
Eclipse.org, and then packed again with a Java 1.5 Pack200.

An interesting observation is that the signer seems to be using Java 1.6. 
But that should be true for all projects (this is the top of the 
ECLIPSE.SF file):

Signature-Version: 1.0 
SHA1-Digest-Manifest: jHnvFjNM4/Rn9koUBVOpVOoWEJY= 
Created-By: 1.6.0 (IBM Corporation) 
SHA1-Digest-Manifest-Main-Attributes: UxN2vuHWF3kmruwHHkDdtAxBZQ4= 

unless this changed very recently of course so that only newly signed 
projects are affected. Could that be the case?

- thomas

I don't know if this makes a difference here since it is complaining about 
a manifest and not a .class file. 
I assume that buckminster.maven contains some classes, so the pack200 tool 
should output a 1.5 compatible  file (assuming they aren't 1.6 classes). 
But the signing and conditioning were done with java 1.5. 

-Andrew 


Thomas Hallgren <thomas@xxxxxxx> 
Sent by: p2-dev-bounces@xxxxxxxxxxx 
05/08/2009 11:45 AM 

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>



To
P2 developer discussions <p2-dev@xxxxxxxxxxx> 
cc

Subject
[p2-dev] Galileo mirroring problem. Need help!








I have a major problem with the P2 mirroring in Galileo Builder. I would 
really appreciate some help pinning it down.

The problem occurs during the mirroring phase. A RawMirrorRequest is 
executed to fetch a xxx.jar.pack.gz file and it succeeds without 
problems. Next, I try to unpack this jar as a sibling. This also 
succeeds on most files, but not all. The problem manifests itself like 
this:

org.eclipse.core.runtime.CoreException: Unable to unpack artifact 
osgi.bundle,org.eclipse.buckminster.maven,1.1.350.r10157 in repository 
file:/shared/galileo/buckyBuild/buildresults/final/aggregate: Error 
reading signed content:/tmp/signatureFile5703.jar
Caused by: java.security.SignatureException: Either the manifest file or 
the signature file has been tampered in this jar: 
/tmp/signatureFile5703.jar

It only manifests itself when running Java 5 on the build machine (a J9 
for ppc). If I run the same build locally on my machine, pointing to the 
exact same repository, everything is fine. Moreover, to verify the 
consistency of the file on the actual machine where it fails, I tested 
using unpack200 (from the same JVM). That completes without problems and 
leaves a resulting jar file. I checked this jar file with jarsigner 
-verify <jar> and it claims the file is OK.

So what can happen here that makes P2 complain when unpacking? And why 
only with one particular VM? Any ideas are greatly appreciated. I'm 
starting to drain out of them.

- thomas
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev



_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
 
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev