Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » Problem with signed and packed plugins
Problem with signed and packed plugins [message #639029] Sun, 14 November 2010 21:41 Go to next message
Thorsten Meinl is currently offline Thorsten MeinlFriend
Messages: 85
Registered: July 2009
Member
Hi all,

I recently tried out to build an US that is both signed *and* packed.
Creation works fine (site.repack -> site.signed -> site.packed ->
site.p2), however, upon installing features from the US I get errors
such as

Problems downloading artifact:
osgi.bundle,org.knime.workbench.editor.svgexport,2.3.0.00277 08.
File has invalid content:/tmp/signatureFile2232226425788850059.jar
Invalid content:META-INF/eclipse.inf
The file "META-INF/eclipse.inf" in the jar
"/tmp/signatureFile2232226425788850059.jar" has been tampered!

The same US works fine if it is either signed or packed, but not both.
Manually unpacking the plugin and then running jarsigner -verify gives
"jar verified.". I've see similar errors while searching the web but no
real solution. Does anyone have an idea what is going wrong here?

Cheers,

Thorsten
Re: Problem with signed and packed plugins [message #639035 is a reply to message #639029] Sun, 14 November 2010 22:51 Go to previous messageGo to next message
Thorsten Meinl is currently offline Thorsten MeinlFriend
Messages: 85
Registered: July 2009
Member
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 #639053 is a reply to message #639035] Mon, 15 November 2010 06:47 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Thorsten Meinl is currently offline Thorsten MeinlFriend
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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
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
Re: Problem with signed and packed plugins [message #639131 is a reply to message #639093] Mon, 15 November 2010 11:45 Go to previous message
Thorsten Meinl is currently offline Thorsten MeinlFriend
Messages: 85
Registered: July 2009
Member
Am 15.11.2010 10:09, schrieb Thomas Hallgren:
> Is there an eclipse.inf present from the very start in any of the
> projects that are included?
No, there is non in any of our projects. They appear for the first time
in the site.repacked folder.
Previous Topic:Source features depends on non-referenced fragment
Next Topic:Product for action X must be a single path
Goto Forum:
  


Current Time: Thu Dec 18 13:35:47 GMT 2014

Powered by FUDForum. Page generated in 0.03251 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software