Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Questions about the JarProcessor


This would be a good enhancement.

I would also suggest that icu and other orbit bundles that shouldn't be packed should ship an eclipse.inf file with
jarprocessor.exclude.pack=true

So that downstream builds don't try to pack them.

-Andrew


Thomas Hallgren <thomas@xxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

05/05/2009 04:28 PM

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

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
Re: [p2-dev] Questions about the JarProcessor





Would it be safe to assume that if the JarProcessor encounters a signed
file, and if that file does not contain the "pack200.conditioned = true"
directive in the eclipse.inf, then it should be left alone? I think that
should work for all cases since it's only for signed files that the
reconditioning is needed.

The only case that would be left out (not packed although it perhaps
would be possible) would be if another tool was used for the
reconditioning that didn't leave the "pack200.contitioned = true" signature.

- thomas

David M Williams wrote:
> 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
> signature.
>
> See bug 263298 for similar issue with the re-signing of nested jars.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=263298
>
>
>
>
>
> From:
> Thomas Hallgren <thomas@xxxxxxx>
> To:
> P2 developer discussions <p2-dev@xxxxxxxxxxx>
> Date:
> 05/05/2009 12:24 PM
> Subject:
> [p2-dev] Questions about the JarProcessor
> Sent by:
> p2-dev-bounces@xxxxxxxxxxx
>
>
>
> 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
> signing info.
>
> - 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


Back to the top