Home » Archived » Buckminster » Problem with signed and packed plugins
| |
| Re: Problem with signed and packed plugins [message #639053 is a reply to message #639035] |
Mon, 15 November 2010 06:47   |
|
Hi Thorsten,
I don't think the eclipse.inf can be the cause. If it is, it cannot be
the only one. Buckminster both signs and packs all jars and we don't
have a handcrafted eclipse.inf present. Everything works anyway and to
my knowledge, there are many projects on the Eclipse release that also
does this without problems.
Also, please note that if you add an eclipse.inf that contains:
eclipse.conditioned = true
then no reconditioning will take place. The jarsigner will see this
property and conclude that it has already been done and the file will
just be packed 'as is' which is a very different behavior from what you
get if that property is not present.
I've seen some problems in this area when using nested jars and mixing
VM used when compiling, packing, and signing. If you compile with 1.6
output for instance, you *must* use a 1.6 VM to recondition, pack, and
unpack.
I've also seen these problems when packing and signing jars with
manifests that already contained the MD5's. Such MD5's must (of course)
be removed before signing.
HTH,
- thomas
On 2010-11-14 23:51, Thorsten Meinl wrote:
> Follow up: If believe I found the cause.
> Buckminster creates (upon repacking) META-INF/eclipse.inf files that
> look like
>
> #Processed using Jarprocessor
> #Sun Nov 14 22:19:20 CET 2010
> pack200.conditioned=true
> pack200.args=-E4
>
> The JarProcessor from P2, which is used when the artifact is downloaded
> and to be installed, re-creates the eclipse.inf upon unpacking and does
> not just decompress it like any other file in the packed jar. The
> recreation (see
> org.eclipse.internal.provisional.equinox.p2.jarprocessor.Jar Processor#recreateJar:134
> and org.eclipse.equinox.internal.p2.jarprocessor.Utils#storeProp erties)
> results in an eclipse.inf like
>
> #Processed using Jarprocessor
> pack200.args = -E4
> pack200.conditioned = true
>
> I.e. the date comment is missing, the properties are sorted and there
> are spaces around the "=". If the jar is now verified it is obvious that
> the signature is invalid since the eclipse.inf is different from that
> having been signed.
> The same happens for all nested jars, thus their signatures are invalid too.
> I'm a bit puzzled as this behaviour should affect *all* packed and
> signed update sites created by Buckminster. So everyone doing this must
> have the same problems except I'm overlooking something.
>
> The fix is also obvious (thus not very easy): create the eclipse.inf in
> Buckminster exactly the same way as the p2 JarProcessor does (see
> org.eclipse.buckminster.jarprocessor.RecursiveConditioner#em itEclipseInf).
>
> Enough work for today ;-)
>
> Good night,
>
> Thorsten
|
|
|
| Re: Problem with signed and packed plugins [message #639092 is a reply to message #639053] |
Mon, 15 November 2010 09:03 |
 Thorsten Meinl
Messages: 85
Registered: July 2009 |
Member |
|
|
Hi Thomas,
> I've seen some problems in this area when using nested jars and mixing
> VM used when compiling, packing, and signing. If you compile with 1.6
> output for instance, you *must* use a 1.6 VM to recondition, pack, and
> unpack.
Everything is done with the same 1.6 JVM (inside Hudson) and some of the
affected bundles do not even contain nested jars.
> I don't think the eclipse.inf can be the cause. If it is, it cannot be
> the only one. Buckminster both signs and packs all jars and we don't
> have a handcrafted eclipse.inf present.
Well, but where does the META-INF/eclipse.inf then come from? It is not
present in the site-folder but in the site.repacked folder with exactly
these contents:
#Processed using Jarprocessor
#Sun Nov 14 22:19:20 CET 2010
pack200.conditioned=true
pack200.args=-E0
> Everything works anyway and to
> my knowledge, there are many projects on the Eclipse release that also
> does this without problems.
This is what I thought, too. But we are just using standard Buckminster
actions.
> I've also seen these problems when packing and signing jars with
> manifests that already contained the MD5's. Such MD5's must (of course)
> be removed before signing.
This is also not the case.
As I have written in my last post, the eclipse.inf *is* different when
unpacked manually compared to when unpacked by p2 and the latter is not
the same as the one in site.repacked which is then used then for
signing, so the cause is - in my eyes - obvious. The question is, why
does it work for other projects but not for ours.
Cheers,
Thorsten
|
|
|
| Re: Problem with signed and packed plugins [message #639093 is a reply to message #639092] |
Mon, 15 November 2010 09:09 |
|
Is there an eclipse.inf present from the very start in any of the projects that are included?
- thomas
On 11/15/2010 10:03 AM, Thorsten Meinl wrote:
> Hi Thomas,
>
>> I've seen some problems in this area when using nested jars and mixing
>> VM used when compiling, packing, and signing. If you compile with 1.6
>> output for instance, you *must* use a 1.6 VM to recondition, pack, and
>> unpack.
> Everything is done with the same 1.6 JVM (inside Hudson) and some of the
> affected bundles do not even contain nested jars.
>
>
>> I don't think the eclipse.inf can be the cause. If it is, it cannot be
>> the only one. Buckminster both signs and packs all jars and we don't
>> have a handcrafted eclipse.inf present.
> Well, but where does the META-INF/eclipse.inf then come from? It is not
> present in the site-folder but in the site.repacked folder with exactly
> these contents:
>
> #Processed using Jarprocessor
> #Sun Nov 14 22:19:20 CET 2010
> pack200.conditioned=true
> pack200.args=-E0
>
>> Everything works anyway and to
>> my knowledge, there are many projects on the Eclipse release that also
>> does this without problems.
> This is what I thought, too. But we are just using standard Buckminster
> actions.
>
>> I've also seen these problems when packing and signing jars with
>> manifests that already contained the MD5's. Such MD5's must (of course)
>> be removed before signing.
> This is also not the case.
>
> As I have written in my last post, the eclipse.inf *is* different when
> unpacked manually compared to when unpacked by p2 and the latter is not
> the same as the one in site.repacked which is then used then for
> signing, so the cause is - in my eyes - obvious. The question is, why
> does it work for other projects but not for ours.
>
> Cheers,
>
> Thorsten
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 01:39:12 GMT 2024
Powered by FUDForum. Page generated in 0.03148 seconds |
] 
Search
Help
Register
Login
Home
