Community
Participate
Working Groups
Looking at the osgi.tests logs for the test failures of the latest CBI based builds [1] I noticed that the following exception is getting thrown when trying to launch a session of eclipse with some security options enabled: Caused by: java.lang.SecurityException: class "org.eclipse.core.runtime.IExtension"'s signer information does not match signer information of other classes in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:806) at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:625) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClassHoldingLock(ClasspathManager.java:638) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:620) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:574) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:492) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:465) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:464) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.eclipse.core.runtime.RegistryFactory.createRegistry(RegistryFactory.java:58) at org.eclipse.core.internal.registry.osgi.Activator.startRegistry(Activator.java:137) at org.eclipse.core.internal.registry.osgi.Activator.start(Activator.java:56) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) ... 69 more This is an indication that the org.eclipse.equinox.registry bundle is not signed with the same signer as the org.eclipse.core.runtime.compatibility.registry bundle. As it turns out both bundles ARE signed with the same signer, but the difference is the inner jar (runtime_registry_compatibility.jar) for the org.eclipse.core.runtime.compatibility.registry bundle is no longer signed in the CBI based build, but it is signed in the PDE based build. [1] - http://download.eclipse.org/eclipse/downloads/drops4cbibased/I20130216-2011/testresults/linux.gtk.x86_6.0/org.eclipse.osgi.tests.AutomatedTests.txt
I released a workaround to disable defining the class with the jar signing certificate to work around the issue for now so we can get green tests from OSGi: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=2bf140c910f5fd4651fcfc798610b7da950d1e51 I do think it is important to figure this one out since a mismatch in the registry host and the compatibility fragment jar have caused us issues in the past.
Would be best to restore same behavior for Kepler (so marked as p2) but believe the severity is correct, normal, not major.
*** Bug 408901 has been marked as a duplicate of this bug. ***
Hi, I was discussing this previously in https://bugs.eclipse.org/bugs/show_bug.cgi?id=408901, and I don't believe this is of normal priority... without that, I simply can't run tests that rely on a classloader (which I think is currently the only way to run a test in Eclipse itself for multiple projects at once). So, this makes http://johanneslink.net/projects/cpsuite.jsp and the junit 3 ClassPathTestCollector unusable, which for me is a real blocker (i.e.: I don't think an Eclipse 4.3 final can be launched without this fixed).
Also see bug 401141 which this bug depends on.
(In reply to comment #4) > Hi, I was discussing this previously in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=408901, and I don't believe > this is of normal priority... without that, I simply can't run tests that > rely on a classloader (which I think is currently the only way to run a test > in Eclipse itself for multiple projects at once). > > So, this makes http://johanneslink.net/projects/cpsuite.jsp and the junit 3 > ClassPathTestCollector unusable, which for me is a real blocker (i.e.: I > don't think an Eclipse 4.3 final can be launched without this fixed). Fabio, since this is a problem for you running unit tests, not in a deployed application, I assume, I am wondering if there is a temporary work-around where you can tell the Java VM to "relax" its security policy's? http://docs.oracle.com/javase/7/docs/technotes/guides/security/ I don't know much about it first hand, but glancing at the above document seemed to provide some techniques/settings to do that. Let us know if that's possible.
(In reply to comment #6) > (In reply to comment #4) > > http://docs.oracle.com/javase/7/docs/technotes/guides/security/ > Or, perhaps try Tom's code workaround in comment 1 link.
FWIW, I wrote a little batch script to see how many "inner jars" we have ... and turns out to be a lot ... but does not really help in knowing which should be signed and which should not be. I've added them as attachments to bug 409074 based on RC2 build.
Setting as SR1 meaning "candidate" ... depends on CBI signer being fixed ... but, this seems pretty important, to me.
David: I don't see a way I can use that workaround from comment when developing things (and couldn't work around it with the security settings either). Is there someone taking a look at this? I'd really like to work with the latest RCs to check if things work, but without this fixed I'm stuck at 4.3m7.
(In reply to comment #9) > Setting as SR1 meaning "candidate" ... depends on CBI signer being fixed ... > but, this seems pretty important, to me. I guess you meant 4.3.1.
*** Bug 411847 has been marked as a duplicate of this bug. ***
Created attachment 234890 [details] innerjars that require action Attached is an edited (simplified) version of the comparator log from I20130828-1800 build. For full log, see http://download.eclipse.org/eclipse/downloads/drops4/I20130828-1800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt The attachment lists bundles who's inner jars differ (due to new builds being signed, but older ones, with same qualifier, are not signed). Now that "signing inner jars" is turned on, there are approximately 70 bundles that require one action or another, directly or indirectly. See http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09638.html for Thanh's announcement of this new function. There are actually two potential actions committers need to take, depending on their requirements: 1. If you WANT the inner jars signed (as in a few equinox cases, maybe others?) then you need to "touch" the bundle so that the qualifier is updated and the version with signed inner jars becomes the distributed one, instead of being replaced by the comparator with an older unsigned version. 2. If you do NOT WANT the inner jars signed (as would be the case with nearly all the test bundles) then you need to A. modify the POM file, as described in bug 412850 comment 28. See also bug 412850 comment 36 for some possibly late breaking news. For those cases where you have a "test parent", you can add the "sign" profile (with the "exclude inner jars = true" setting), just to that test parent and it will be inherited. B. AND ... THEN you MIGHT need to touch the bundles involved so the "not signed" version becomes most current and becomes the distributed one (this depends on if the bundle has changed, for other reasons, and the signed version is now current. It's fine to do in several passes, and see what the comparator and unit tests report. I'm going to propose we do I builds every night for a week or so so progress can be more incremental.
(In reply to comment #13) > 2. If you do NOT WANT the inner jars signed (as would be the case with > nearly all the test bundles) then you need to > > A. modify the POM file, as described in bug 412850 comment 28. See also bug > 412850 comment 36 for some possibly late breaking news. > For those cases where you have a "test parent", you can add the "sign" > profile (with the "exclude inner jars = true" setting), just to that test > parent and it will be inherited. > > B. AND ... THEN you MIGHT need to touch the bundles involved so the "not > signed" version becomes most current and becomes the distributed one (this > depends on if the bundle has changed, for other reasons, and the signed > version is now current. Isn't the information in the 'eclipse.inf': jarprocessor.exclude.pack=true jarprocessor.exclude.children=true4 used? JDT Core tests specify this, but their inner JAR still seems to get signed (see bug 416106).
(In reply to comment #14) > (In reply to comment #13) > > 2. If you do NOT WANT the inner jars signed (as would be the case with > > nearly all the test bundles) then you need to > > > > A. modify the POM file, as described in bug 412850 comment 28. See also bug > > 412850 comment 36 for some possibly late breaking news. > > For those cases where you have a "test parent", you can add the "sign" > > profile (with the "exclude inner jars = true" setting), just to that test > > parent and it will be inherited. > > > > B. AND ... THEN you MIGHT need to touch the bundles involved so the "not > > signed" version becomes most current and becomes the distributed one (this > > depends on if the bundle has changed, for other reasons, and the signed > > version is now current. > > Isn't the information in the 'eclipse.inf': > jarprocessor.exclude.pack=true > jarprocessor.exclude.children=true4 > used? JDT Core tests specify this, but their inner JAR still seems to get > signed (see bug 416106). No, not used by Tycho. There is a number of bugs about this, but bottom line is they only partially support "eclipse.inf" at all. I'm "lost in the maze of bugs" at the moment, and can't point you to specific bug numbers.
(In reply to comment #15) > No, not used by Tycho. There is a number of bugs about this, but bottom line > is they only partially support "eclipse.inf" at all. I'm "lost in the maze > of bugs" at the moment, and can't point you to specific bug numbers. We've proposed 2 different methods. The first method (bug 401141) we were going to depend on the existing MANIFEST.MF to allow excluding children but it caused Bug 412850 due to Tycho not supporting the MANIFEST.MF file to which we raised bug 413282 but it appears it may be difficult to implement in Tycho. So we decided to go with method 2 which is to fix it in CBI's jarsigner plugin by adding the new pom configuration.
(In reply to comment #16) > We've proposed 2 different methods. The first method (bug 401141) we were > going to depend on the existing MANIFEST.MF to allow excluding children but > it caused Bug 412850 due to Tycho not supporting the MANIFEST.MF file to > which we raised bug 413282 but it appears it may be difficult to implement > in Tycho. And by MANIFEST.MF I meant eclipse.inf sorry...
(In reply to David Williams from comment #13) > 2. If you do NOT WANT the inner jars signed (as would be the case with > nearly all the test bundles) then you need to For most test bundles signing won't hurt and hence touching them is enough. However, we need to exclude signing for all JARs that contain Ant tasks to avoid performance penalties (for details see bug 163549 comment 0). I've disabled inner JAR signing for the following bundles: org.eclipse.ant.core org.eclipse.ant.launching org.eclipse.ant.ui org.eclipse.help.base org.eclipse.jdt.core org.eclipse.pde.core
(In reply to Dani Megert from comment #18) > (In reply to David Williams from comment #13) > > 2. If you do NOT WANT the inner jars signed (as would be the case with > > nearly all the test bundles) then you need to > > For most test bundles signing won't hurt and hence touching them is enough. > However, we need to exclude signing for all JARs that contain Ant tasks to > avoid performance penalties (for details see bug 163549 comment 0). I've > disabled inner JAR signing for the following bundles: > > org.eclipse.ant.core > org.eclipse.ant.launching > org.eclipse.ant.ui > org.eclipse.help.base > org.eclipse.jdt.core > org.eclipse.pde.core I also seem some of those in Equinox.
(In reply to Dani Megert from comment #18) > (In reply to David Williams from comment #13) > > 2. If you do NOT WANT the inner jars signed (as would be the case with > > nearly all the test bundles) then you need to > > For most test bundles signing won't hurt and hence touching them is enough. > However, we need to exclude signing for all JARs that contain Ant tasks to > avoid performance penalties (for details see bug 163549 comment 0). I've > disabled inner JAR signing for the following bundles: > > org.eclipse.ant.core > org.eclipse.ant.launching > org.eclipse.ant.ui > org.eclipse.help.base > org.eclipse.jdt.core > org.eclipse.pde.core And done for org.eclipse.pde.api.tools
(In reply to Dani Megert from comment #19) > (In reply to Dani Megert from comment #18) > > (In reply to David Williams from comment #13) > > > 2. If you do NOT WANT the inner jars signed (as would be the case with > > > nearly all the test bundles) then you need to > > > > For most test bundles signing won't hurt and hence touching them is enough. > > However, we need to exclude signing for all JARs that contain Ant tasks to > > avoid performance penalties (for details see bug 163549 comment 0). I've > > disabled inner JAR signing for the following bundles: > > > > org.eclipse.ant.core > > org.eclipse.ant.launching > > org.eclipse.ant.ui > > org.eclipse.help.base > > org.eclipse.jdt.core > > org.eclipse.pde.core > > I also seem some of those in Equinox. Equinox probably requires the most care. This whole issue, that is, the need to sign inner jars ... came about because some in some cases (especially where a bundle or extension framework has its own classloader) "split packages" and "hosts with fragments" must be "signed by the same certificate" or the classloader is flag as invalid. I'm probably not verbalizing that well (need another cup of tea) but comment 0 probably says it well enough and I'm just urging caution.
There hasn't been much progress lately. Note that M2 is already next week, so please take a look at your component(s) if not done so already.
(In reply to Dani Megert from comment #22) > There hasn't been much progress lately. Note that M2 is already next week, > so please take a look at your component(s) if not done so already. Equinox should be fine. I disabled signing of inner jars for the tests. p2 also has done the same. All other inner jars in Equinox should be signed.
(In reply to Thomas Watson from comment #23) > (In reply to Dani Megert from comment #22) > > There hasn't been much progress lately. Note that M2 is already next week, > > so please take a look at your component(s) if not done so already. > > Equinox should be fine. I disabled signing of inner jars for the tests. p2 > also has done the same. All other inner jars in Equinox should be signed. I've not looked, but assumed you "touched" those you want signed? Otherwise, qualifier won't change, and and old unsigned version will be pulled in by "comparator".
The inner jar associated with equinox (but is really part of Platform->Core) was touched as part of bug 412852 where the version was increased for Luna.
The following inner JARs that are inside a directory (non-JARed plug-in), are still not signed: runtime_registry_compatibility.jar in org.eclipse.core.runtime.compatibility.registry pdebuild.jar in org.eclipse.pde.build
(In reply to Dani Megert from comment #26) > pdebuild.jar in org.eclipse.pde.build This is actually expected, but shows the limitations of the current approach: I can only specify that a plug-in with all its inner JARs is excluded. 'org.eclipse.pde.build' is shipped as non-JARed bundle where we would want to sign the 'pdebuild.jar' that has the "normal" class files, but we'd like to exclude the library which contains the Ant tasks from signing (lib/pdebuild-ant.jar). As far as I know this is currently not possible. In PDE Build one could simply specify this per JAR via 'eclipse.inf'.
(In reply to Dani Megert from comment #26) > The following inner JARs that are inside a directory (non-JARed plug-in), > are still not signed: > > runtime_registry_compatibility.jar in > org.eclipse.core.runtime.compatibility.registry I touched the bundle again: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=e7ac5a380f7b7c4d2f9e07eb8ab79363bda13f8a Not sure when the signing got lost on it again.
(In reply to Thomas Watson from comment #28) > (In reply to Dani Megert from comment #26) > > The following inner JARs that are inside a directory (non-JARed plug-in), > > are still not signed: > > > > runtime_registry_compatibility.jar in > > org.eclipse.core.runtime.compatibility.registry > > I touched the bundle again: > > http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > ?id=e7ac5a380f7b7c4d2f9e07eb8ab79363bda13f8a > > Not sure when the signing got lost on it again. Looks good now. Closing as FIXED.
Can you fix this bug in version 4.3.2? The problem still exists in 4.3.2 RC1 and Maintenance Build: M20140122-1000
(In reply to Beck Yang from comment #30) > Can you fix this bug in version 4.3.2? > The problem still exists in 4.3.2 RC1 and Maintenance Build: M20140122-1000 That was certainly our original intent, since its obviously important to some people, but it turned out to be more change (and work) than we originally thought, so I certainly do not have the authority to decide. Dani, and Tom, I think the decision is up to you too. I know from a "releng" point of view, we would have to change the version of tycho and cbi we use in maintenance. I think in general this is very low risk ... but, if I recall, where were a few tweaks we had to make (that were not related to inner jar signing). What we currently use, in master, is <tycho.version>0.19.0</tycho.version> <tycho-extras.version>0.19.0</tycho-extras.version> <cbi-plugins.version>1.0.5</cbi-plugins.version> (and 0.18.1, and 1.0.4, in maintenance). The other factor is that several bundles need to copy/paste the "inner signing off" code to their POMs and then to be "touched". In other words, a fair amount of work to do in one week, for RC2. I certainly don't mind ... but know there are many other priorities, so it is a "tough call". Beck, and others that need this in "Kepler" ... I suggest you state, again, why you consider it "blocking" and what impact it would have if not fixed.
(In reply to David Williams from comment #31) > (In reply to Beck Yang from comment #30) > > Can you fix this bug in version 4.3.2? > > The problem still exists in 4.3.2 RC1 and Maintenance Build: M20140122-1000 > > That was certainly our original intent, since its obviously important to > some people, but it turned out to be more change (and work) than we > originally thought, so I certainly do not have the authority to decide. > > Dani, and Tom, I think the decision is up to you too. No, we won't backport this. As mentioned, many changes were involved and RC2 is tomorrow. Also note that even with the fix, i.e. in 4.4 M5, we have several inner JARs that aren't and can't be signed (e.g. all those with Ant tasks). Plus, some bundles from Orbit also don't have their inner JAR(s) signed (e.g. 'org.junit').
(In reply to Thomas Watson from comment #1) > I released a workaround to disable defining the class with the jar signing > certificate to work around the issue for now so we can get green tests from > OSGi: > > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/ > ?id=2bf140c910f5fd4651fcfc798610b7da950d1e51 > > > I do think it is important to figure this one out since a mismatch in the > registry host and the compatibility fragment jar have caused us issues in > the past. How to apply the solution mentioned in the comment. I am facing the same issue while testing my eclipse rcp plugin using powermock and mockito. I am not sure how can I implement your solution. Please help.
(In reply to Ashish Tyagi from comment #33) > How to apply the solution mentioned in the comment. I am facing the same > issue while testing my eclipse rcp plugin using powermock and mockito. I am > not sure how can I implement your solution. Please help. I suspect when you are mocking for tests it is not running in an Equinox OSGi framework like is done when launching the actual RCP application. Outside of an Equinox OSGi framework the code is likely loaded by a "normal" URLClassLoader. It is not possible to configure these class loaders to ignore signatures at class definition time like we can do for the OSGi bundle class loaders. How is your testing failing? What is the stacktrace and error message? If it is what I suspect you would have to strip the jars of their signatures to workaround it.
