[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] Questions about the JarProcessor
The ICU bundles are some we get "pre-built", so in Orbit we consciously
do not normalize them (and you should not either :)
I'd agree that's not obvious, and not sure how to make that more obvious.
But, yes, it means they can not be packed with pack200 if the provider
does not do the normalization (I'm surprised they don't).
But, I agree, jar processor should not change contents and break a
See bug 263298 for similar issue with the re-signing of nested jars.
Thomas Hallgren <thomas@xxxxxxx>
P2 developer discussions <p2-dev@xxxxxxxxxxx>
05/05/2009 12:24 PM
[p2-dev] Questions about the JarProcessor
We bundle the com.ibm.icu.base plug-in on our headless update site. We
pick it from Orbit where it's signed. There is however no pack200
artifact so we try to create the pack.gz when we publish our site. That
turns out to be tricky:
The JarProcessor reads the eclipse.inf from the META-INF folder of the
jar. That file contains one line:
#Processed using Jarprocessor
This is not sufficient for the JarProcessor. It adds:
pack200.conditioned = true
and then it recreates the jar file. Next, it attempts to run pack200 on
the file. Not surprisingly, that fails with:
Exception in thread "main" java.lang.SecurityException: SHA1 digest
error for META-INF/eclipse.inf
This seems like a bug to me. If the jar processor encounters a signed
jar file it has two options:
1. Leave the file alone.
2. Remove all signing information from the file when recreating it.
Altering a signed file while retaining the digests can *never* be the
right thing to do. If I provide a patch for this, what approach would
you consider correct? Should this be controlled by an option? My
personal opinion is that no option is needed and that the JarProcessor
do #1 in all cases. The pack step in particular needs to retain the
p2-dev mailing list