Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #188305 +++ When running Eclipse 3.3RC1 update manager to get a signed and packed feature from my update site, I'm seeing a signature verification error on Linux x86_64. Doing the same with Eclipse 3.3M7 on the same machine, I even get a JVM error and forced abort. This is a blocker because with the error, installing from the update site is not possible on Linux x86_64 and we'd need to revert to unsigned update site if this cannot be fixed. The error does NOT occur on a 32-bit Linux RHEL4 with Sun Java 6u1, so I assume that my features and plugins are correct but there is a bug in update manager (and/or the JDK). Here are the details from bug #188305: eclipse-platform-3.3RC1-linux-gtk-x86_64 on a Sun 1.5.0_10 VM on openSUSE 10.2 Help > Software Updates > Find and Install > Search for New Features Add site: http://download.eclipse.org/dsdp/tm/updates/milestones Select RSE End-User Runtime / Remote System Explorer Core only Next, Accept, Next, Finish, Install --> This error is shown: Problem occurred 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/1179838271359/1179838271488/eclipse36025.tmp has been removed from the bundle: systemsImportExport.jar] A file /tmp/982347861/eclipse/.update/1179838271359/1179838271488/eclipse36025.tmp has been removed from the bundle: systemsImportExport.jar Verification of feature unsuccessful. Installation cancelled. [A file /tmp/982347861/eclipse/.update/1179838271359/1179838271488/eclipse36025.tmp has been removed from the bundle: systemsImportExport.jar] A file /tmp/982347861/eclipse/.update/1179838271359/1179838271488/eclipse36025.tmp has been removed from the bundle: systemsImportExport.jar
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.
