Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 168583

Summary: [JarProcessor] Processor can change hash of eclipse.inf
Product: [Eclipse Project] Platform Reporter: Andrew Niefer <aniefer>
Component: Update (deprecated - use Eclipse>Equinox>p2)Assignee: Platform-Update-Inbox <platform-update-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: bluesoldier, jeffmcaffer, john.arthorne, mober.at+eclipse, sonia_dimitrov, wmitsuda
Version: 3.3   
Target Milestone: 3.3 M5   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on:    
Bug Blocks: 163421, 168594, 175284    
Attachments:
Description Flags
patch none

Description Andrew Niefer CLA 2006-12-19 13:49:51 EST 
When performing an operation on a signed jar that should not change the hash, ie a repack, or the no-op processing seen in bug 168579, the jar processor can change the hash of the eclipse.inf causing the result to fail verification.

This will happen when the jar is signed on a different platform than the one where the later processing occurs.
ex: sign on linux, pack on windows.

The change comes from the different line endings on the different platforms: \n vs \r\n.
Comment 1 Andrew Niefer CLA 2006-12-19 14:02:07 EST 
Need to check to see if this is a problem when unpacking signed & packed jars.
For example, the jars were signed on linux, but we are doing an update on a windows box.  Perhaps this is the cause of bug 163421
Comment 2 Andrew Niefer CLA 2006-12-19 14:06:06 EST 
Created attachment 55921 [details]
patch

Attached patch fixes problem by always using \n
Comment 3 Martin Oberhuber CLA 2006-12-19 14:22:02 EST 
Whoa! This could also be the reason for bug 168344.
Thanks for putting me on CC for this.

As a matter of fact, in all the cases where I saw problems, the signing had been done on Linux, unpacking on Windows, and the verification error was seen in the file Eclipse.inf. If this is the true issue, it would be a big problem for Europa M4 (in case the update site should be signed & packed).

The strange thing with bug 168344 is, that most features unpacked and verified properly (e.g. rse.core, rse.ftp, rse.ssh) while some threw the verification exception (rse.examples, rse.sdk) - though all were processed in the same way.
Comment 4 John Arthorne CLA 2006-12-19 15:07:21 EST 
Martin, I wouldn't be surprised if this is the cause of the problem in your case.  If you are still following the steps in bug 163421 comment #4, you are doing a redundant -repack before calling the signing script (because the signing script also does a repack before signing).  Eliminating this redundant repack my also solve your problem...
Comment 5 Martin Oberhuber CLA 2006-12-19 15:12:07 EST 
But by the definition of repack, if repack happens on the _same_ platform twice it shouldn't change anything? Andrew was referring to multiple-repack issues when happening on _different_ platforms (windows / linux).
Comment 6 John Arthorne CLA 2006-12-19 15:22:38 EST 
Oh right, I assume you are running all of this on the same machine (build.eclipse.org). In the platform build, we only run the signing script on build.eclipse.org, and do other processing of JARs back on our local build machine. So perhaps in your case this problem doesn't apply. I still think you should remove the extra -repack step just to eliminate variables that may be causing the problem.
Comment 7 Dejan Glozic CLA 2006-12-20 10:23:41 EST 
Released.
Comment 8 Martin Oberhuber CLA 2007-02-23 09:38:30 EST 
It looks like a new manifestation of the issue is in bug 175284, visible on the
Eclipse Platform M5 milestone update site.
I'm not reopening the bug, though, because I'm not sure if the hash is the real cause of the issue.