Bugzilla – Full Text Bug Listing
| Summary: | Unable to load classes when running test cases because of java.lang.SecurityException because signer information is invalid | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Fabio Zadrozny <fabiofz> | ||||
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | david_williams, pwebster, tjwatson | ||||
| Version: | 3.9.0 Kepler | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Fabio Zadrozny
We have packages that are spread amongst multiple jars, that we don't have problems loading with the OSGi classloader. AFAIK we don't require that classes in the same package be signed by the same signer, only that the part of the package within on jar is. PW We've seen this sort of thing before, Such as see Orbit's bug 403486, especially Tom's comment 4 there. But, I would be surprised if there are any of the "platform's bundles" or fragments that are signed by different certificates, in any current drop of ours. Fabio, can you detail a little more what your "setup" is? Such as where do all your bundles come from? All from the same "drop"? By any chance, are you testing these directly from the IDE, and perhaps testing a "new drop" in an IDE based on an "older version" of the platform? If so, you might have to update your dev. environment to get all the signatures certs to match. And, BTW, it is entirely possible that for M5a we were using bundles that had not changed for a long time (e.g. since last release) and now, moving to new build technology, etc., I suspect all our bundles have been "incremented" and signed with latest certificate. For the record, I just happened to be looking at our signatures for RC2 candidate, so did a quick peek and appears only these third party bundles are signed with "older" certificates (all still valid ... just different). I can't imagine any of them have the org.eclipse.core.runtime package in them ... I don't think any of them are fragments ... or "framework extensions" ... but, not positive. org.aspectj.runtime might be? javax.inject_1.0.0.v20091030.jar javax.xml_1.3.4.v201005080400.jar org.apache.batik.css_1.6.0.v201011041432.jar org.apache.batik.util.gui_1.6.0.v201011041432.jar org.apache.batik.util_1.6.0.v201011041432.jar org.apache.commons.httpclient_3.1.0.v201012070820.jar org.apache.commons.logging.source_1.1.1.v201101211721.jar org.apache.commons.logging_1.1.1.v201101211721.jar org.aspectj.runtime_1.7.3.20130403143700.jar org.easymock_2.4.0.v20090202-0900.jar org.objectweb.asm.source_3.3.1.v201105211655.jar org.objectweb.asm_3.3.1.v201105211655.jar org.w3c.css.sac_1.3.1.v200903091627.jar org.w3c.dom.smil_1.0.0.v200806040011.jar org.w3c.dom.svg_1.1.0.v201011041433.jar So be sure you're running tests from latest IDE (if that is your setup) and if not, see if you help us narrow down which "package" is in conflict. Thanks, My setup is pretty simple as I just grabbed the SDK without installing anything else. The exact steps are (note: using git from the command line to avoid egit dep): 1. Unzip the code from: http://download.eclipse.org/eclipse/downloads/drops4/S-4.3RC1-201305162200/, gotten the win32 version (http://download.eclipse.org/eclipse/downloads/drops4/S-4.3RC1-201305162200/download.php?dropFile=eclipse-SDK-4.3RC1-win32.zip) 2. Get the PyDev sources from https://github.com/fabioz/Pydev, import all the projects from the PyDev development branch (except the mylyn-related ones). 3.After the import, right-click /com.python.pydev.runalltests/src/com/python/pydev/runalltests2/AllTests.java, run as > Junit test (that uses the junit3 backported version, but the stack trace is very similar). Note that just for testing, I've also gotten 4.3m7 from the site and it works properly there, so, this is something that happened when going from 4.3m7 to 4.3rc1. (In reply to comment #3) > > Note that just for testing, I've also gotten 4.3m7 from the site and it > works properly there, so, this is something that happened when going from > 4.3m7 to 4.3rc1. Now you have me intrigued! :) I hope to find time to try and reproduce, but in the mean time, could you try the build from http://download.eclipse.org/eclipse/downloads/drops4/I20130523-1400/ That is our proposed RC2 version and I'm anxious to see if it has the same issue. If it does, then please attach your "configuration" (available from About box, Installation details, Configuration page). I just want to know what VM you are using, etc. And, to cover the obvious ... did you check the "integrity" of the download of RC1, such comparing out SHA1 value with what's would be computed on your system? Such as, see our http://download.eclipse.org/eclipse/downloads/drops4/S-4.3RC1-201305162200/checksum/eclipse-SDK-4.3RC1-win32.zip.sha1 See http://download.eclipse.org/eclipse/downloads/drops4/I20130523-1400/verifyMD5.html if you don't know what I'm talking about :) Created attachment 231465 [details]
Configuration from the RC2 passed
I've checked the RC2 and it has the same issue (and just to note, this time I got the 64 bit and not the 32 bit version). I've added the configuration as requested. I checked the md5 for the RC1 and it did match. Moving the releng, nothing the framework can do here since it appears this is a non-OSGi environment in which the jars are getting loaded. But as David mentions the certificates should all be identical for the RC1 build. This is a dup of bug 401098. The issue is the inner jars are no longer signed since the move to CBI. The registry compatibility fragment has an inner jar that contributes to the org.eclipse.core.runtime package. *** This bug has been marked as a duplicate of bug 401098 *** |