Bugzilla – Full Text Bug Listing
| Summary: | Signature verification error on Linux x86_64 with signed, packed, nested jar | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||||
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Platform-Update-Inbox <platform-update-inbox> | ||||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | aniefer | ||||||||
| Version: | 3.3 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | 163421, 175284 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Martin Oberhuber
Re-tried with Sun Java 6u1 on x86_64 and it worked OK. Re-tried with Sun Java 1.5.0_11 on x86_64 and it failed. Re-tried with Sun Java 1.5.0_11 on Linux 32-bit and it worked OK. Not sure if Platform/Update should analyze the issue and find a way to make it work with Sun JDK 1.5 on x86_64 as well... probably yes, since 1.5 is still the most widely used JDK? I have not been able to reproduce this. It worked for me on x86_64 using sun 1.5.0_09, _10, and _11. Thanks for trying, Andrew - I'm stunned that you cannot reproduce this. Did you try exactly the update site and the feature specified in the description? Are you sure you ran in 64 bit mode (sun jdk-1.5.0-linux-amd64)? What kind of system did you try on - result of uname -a cat /etc/*-releas* ? I notice that Red Hat Enterprise Linux 4.0 update 2, x86-64, GTK is the reference platform for Linux x86_64 so I'll try to investigate more if I have time. Anyways, I'm reducing severity to Normal since there is a workaround (using Sun Java 6u1). It turned out that the concrete problem I was having with this (see bug #188305) was due to a signed, packed, nested jar in the bundle -- a situation similar to the one described in bug #163421 for Windows, but this time on Linux x86_64 with the Sun 1.5 JVM only. I have resolved the concrete issue by avoiding the nested jar, so this might be a workaround for other similar problems as well: avoid the nested jar or mark it as do not sign / do not pack as described for pde.build in bug #175284 comment 27: Add a Property to Eclipse.inf file in META-INF folder specifying jarprocessor.exclude.children=true Created attachment 68564 [details]
Original signed, unpacked jar
Attaching the problematic signed, unpacked jar with the nested jar because this is going to vanish from our update site eventually
Created attachment 68566 [details]
Packed, signed jar
Attaching the problematic signed, packed jar with the nested jar because this is going to vanish from our update site eventually.
Packing was done with releng.basebuilder M7i_33
(In reply to comment #3) I tried 1.5.0_10 and _11 on SUSE: Linux 2.6.5-7.283-smp #1 SMP Wed Nov 29 16:55:53 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux LSB_VERSION="1.3" SUSE LINUX Enterprise Server 9 (x86_64) VERSION = 9 PATCHLEVEL = 3 I also tried 1.5.0_09 and 1.5.0_10 on Linux 2.6.9-42.EL #1 Wed Jul 12 23:15:20 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux WS release 4 (Nahant Update 4) All the vms are amd64 The feature that was installed is org.eclipse.rse.core_2.0.0.v20070518-7N--EAAoOPoPOckB I will take a look at the attached jars The attached packed & signed jar unpacks and verifies successfully for me. How did you test it such that I could re-try it on my machine? You can unpack it with something like the following: java -jar plugins/org.eclipse.equinox.launcher_1.0.0.v20070515.jar -application org.eclipse.update.core.siteOptimizer -jarProcessor -verbose -unpack -outputDir out org.eclipse.rse.importexport_1.0.0.v20070516.jar.pack.gz and then run jarsigner -verify on the result found in out/ I tried from the commandline as you suggested, and it worked fine. Then I tried from the UI (Update manager) but it still failed with this message: Unable to complete action for feature "Remote System Explorer Core" due to errors. Verification of feature unsuccessful. Installation cancelled. [A file /tmp/982347861/eclipse/.update/1180084518732/1180084518734/eclipse22833.tmp has been removed from the bundle: systemsImportExport.jar] A file /tmp/982347861/eclipse/.update/1180084518732/1180084518734/eclipse22833.tmp has been removed from the bundle: systemsImportExport.jar Verification of feature unsuccessful. Installation cancelled. [A file /tmp/982347861/eclipse/.update/1180084518732/1180084518734/eclipse22833.tmp has been removed from the bundle: systemsImportExport.jar] A file /tmp/982347861/eclipse/.update/1180084518732/1180084518734/eclipse22833.tmp has been removed from the bundle: systemsImportExport.jar For further analysis, I uploaded the contents of the tmp directory /tmp/982347861/eclipse/.update/1180084518732/1180084518734 to http://download.eclipse.org/dsdp/tm/div/bug188309-verify-x86_64/1180084518734.tgz I notice that there is some files like feature.properties residing in that directory directly (shouldn't they be in subdirectories?) and I notice the directory "temp_1_systemsImportExport.jar" which seems differently named than the others. Perhaps this helps... Created attachment 68747 [details]
Configuration details of my machine
I finally debugged this with a Java breackpoint set on all constructors of Throwable, and found that I ran into the following three exceptions during verification. It looks like the middle one (CEStreamExhausted) is the reason for the problem:
1. ClassNotFoundException: org/eclipse/osgi/internal/verifier/JarVerifierMessages
ClassNotFoundException.<init>(String) line: 65
ClassLoader.findBootstrapClass(String) line: not available [native method]
Main$StartupClassLoader(ClassLoader).findBootstrapClass0(String) line: 891
Main$StartupClassLoader(ClassLoader).loadClass(String, boolean) line: 301
Main$StartupClassLoader(ClassLoader).loadClass(String) line: 251
Main$StartupClassLoader(ClassLoader).loadClassInternal(String) line: 319
SignedBundleFile.getEntry(String) line: 597
SignedBundleFile.verifyContent() line: 712
CertVerifier.verifyIntegrity(CertificateVerifier, String) line: 182
2. CEStreamExhausted.<init>() line: 12
BASE64Decoder.decodeAtom(PushbackInputStream, OutputStream, int) line: 100
BASE64Decoder(CharacterDecoder).decodeBuffer(InputStream, OutputStream) line: 146
BASE64Decoder(CharacterDecoder).decodeBuffer(String) line: 177
ManifestEntryVerifier.setEntry(String, JarEntry) line: 127
JarVerifier.beginEntry(JarEntry, ManifestEntryVerifier) line: 145
JarVerifier$VerifierStream.<init>(Manifest, JarEntry, InputStream, JarVerifier) line: 373
JarFile.getInputStream(ZipEntry) line: 400
URLClassPath$JarLoader$1.getInputStream() line: 620
URLClassPath$JarLoader$1(Resource).cachedInputStream() line: 58
URLClassPath$JarLoader$1(Resource).getByteBuffer() line: 113
Main$StartupClassLoader(URLClassLoader).defineClass(String, Resource) line: 249
URLClassLoader.access$100(URLClassLoader, String, Resource) line: 56
URLClassLoader$1.run() line: 195
AccessController.doPrivileged(PrivilegedExceptionAction<T>, AccessControlContext) line: not available [native method]
Main$StartupClassLoader(URLClassLoader).findClass(String) line: 188
Main$StartupClassLoader(ClassLoader).loadClass(String, boolean) line: 306
Main$StartupClassLoader(ClassLoader).loadClass(String) line: 251
Main$StartupClassLoader(ClassLoader).loadClassInternal(String) line: 319
SignedBundleFile.getEntry(String) line: 597
SignedBundleFile.verifyContent() line: 712
CertVerifier.verifyIntegrity(CertificateVerifier, String) line: 182
CertVerifier.verify(String, String) line: 149
CertVerifier.verify(IFeature, ContentReference, boolean, InstallMonitor) line: 133
Feature.verifyReferences(IVerifier, ContentReference[], InstallMonitor, IVerificationListener, boolean) line: 967
Feature.install(IFeature, IFeatureReference[], IVerificationListener, IProgressMonitor) line: 377
3. SecurityException
With a contents as shown in the dialog. So, I assume the "CEStreamExhausted"
exception is the original reason of this problem.
Martin, I would guess that the CEStreamExhausted is expected in this case and comes from the systemsImportExport.jar not being in the jar being verified.
Looking at your tgz, this is what I see:
1) eclipse22833.temp.pack.gz is our downloaded jar.pack.gz we care about
2) It is unpacked, resulting in eclipse22833.temp. (This is a jar, inspecting it reveals as expected a nested systemsImportExport.jar.pack.gz file)
3) The nested pack.gz file is extracted to temp.eclipse22833.tmp/systemsImportExport.jar.pack.gz
3a) systemsImportExport.jar.pack.gz is unpacked, see the resulting temp.eclipse22833.tmp/systemsImportExport.jar as expected in your tgz.
4) systemsImportExport.jar is considered for recursion.
ME: a) systemsImportExport.jar is recreated at /temp_1_systemsImportExport.jar/systemsImportExport.jar
b) eclipse22833.tmp gets recreated with systemsImportExport.jar replacing systemsImportExport.jar.pack.gz.
c) everyone is happy
YOU: a) notice in your tgz file /temp_1_systemsImportExport.jar/systemsImportExport.jar is size 0.
I expect an exception occured here.
The result of this exception is the processing of eclipse22833 is aborted, leaving behind the eclipse22833.tmp containing the systemsImportExport.jar.pack.gz which is later consider for verification and failing.
If you are debugging this, I would suggest a breakpoint in org.eclipse.update.internal.jarprocessor.JarProcessor.recreateJar.
Or, in org.eclipse.update.internal.core.FreaturePackagedContentProvider.retrieveLocalJar, use the debugger to change the JarProcessor to have verbose=true to see if any stack traces are printed to stdout.
I'm not going to work on this any more, and guess that the issue has since been fixed through other related work on signing, packing and nested jars. I propose marking this WORKSFORME with target milestone 3.4. Closing. See comment #15. |