Community
Participate
Working Groups
The latest Orbit repository contains bundles which are signed with an old certifcate of Eclipse. For Equinox this is not a big deal because it ignores the signing information. But if you're using these bundles with a different classloader as the one from Equinox you're getting the following exception: java.lang.SecurityException: class "org.apache.commons.collections.BeanMap"'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 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) Exactly this was happing for the Stardust project. They're using org.apache.commons.beanutils_1.8.0.v201205091237.jar and org.apache.commons.collections_3.2.0.v201005080500.jar bundles from the R20130118183705 Orbit repository and have deployed these into a Tomcat server. According to https://bugs.eclipse.org/bugs/show_bug.cgi?id=362445 it seems that the certificate was changed in the first quarter of 2012. IMO all bundles with a timestamp older than 2012-04-04 should be updated.
I'm happy to touch ones you have problems with, but don't especially like the idea of touching them all. Certificates only last 2 or 3 years, and doesn't seem right we should have to re-sign all our bundles just because a perfectly valid certificate and signed bundle changed in more recent ones. Unless someone knows otherwise. But, I do understand your issue in this case of these two bundles so would be happy to touch the older one. Do you anticipate others?
(In reply to comment #1) > I'm happy to touch ones you have problems with, but don't especially like > the idea of touching them all. Certificates only last 2 or 3 years, and > doesn't seem right we should have to re-sign all our bundles just because a > perfectly valid certificate and signed bundle changed in more recent ones. > > Unless someone knows otherwise. > > But, I do understand your issue in this case of these two bundles so would > be happy to touch the older one. Do you anticipate others? To be a little clearer ... I think its the 'same package' issue that's important here. If that'd help you narrow down a list.
Ok - I can see the point...using a sledgehammer to crack a nut can be a risky thing and I must admit that I'm also unsure about the consequences here. So it would be great if you could at least touch org.apache.commons.collections_3.2.0.v201005080500.jar for the moment. Unfortunately I'm on leave until the end of the next week. So I cannot look for potentially more bundles but I'll drop a mail to other Stardust committers if they can have a look into this.
I agree with David, we should only touch the bundles we find issues with. For this particular issue it is when a package is split across multiple jars and the jars will be loaded with the same class loader. This can happen in OSGi also when a fragment contributes to a package contained in the host.
I looked a little closer at this, and found its not a typical case of "split package" bundle, if there is such a thing. The beanutils bundle does contain 4 classes from org.apache.commons.collections, but imports the rest, and does not export its own versions of the 4 collections classes. In fact, they are marked as Private-Package: org.apache.commons.collections;version="1.8.0" I've not seen that before and not sure exactly what it means. I don't think that changes anything on what "needs to be done" (that is, touch the collections bundle so it gets resigned with current certificate) but ... makes me wonder if the beanutils bundle is correct? Or, at least, if its "good form" to have these "private packages"? = = = = = = Manifest-Version: 1.0 Import-Package: org.apache.commons.beanutils;version="1.8.0", org.apache.commons.beanutils.converters;version="1.8.0", org.apache.commons.beanutils.expression;version="1.8.0", org.apache.commons.beanutils.locale;version="1.8.0", org.apache.commons.beanutils.locale.converters;version="1.8.0", org.apache.commons.collections.comparators, org.apache.commons.collections.keyvalue, org.apache.commons.collections.list, org.apache.commons.collections.set, org.apache.commons.logging Export-Package: org.apache.commons.beanutils.expression;version="1.8.0", org.apache.commons.beanutils;version="1.8.0", org.apache.commons.beanutils.locale.converters;version="1.8.0", org.apache.commons.beanutils.converters;version="1.8.0", org.apache.commons.beanutils.locale;version="1.8.0" Bundle-Name: %pluginName Bundle-Vendor: %providerName Bundle-Localization: plugin Bundle-Version: 1.8.0.qualifier Ignore-Package: org.apache.commons.collections Bundle-Description: BeanUtils provides an easy-to-use but flexible wrapper around reflection and introspection. Private-Package: org.apache.commons.collections;version="1.8.0" Bundle-DocURL: http://commons.apache.org/beanutils/ Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.apache.commons.beanutils
Adding Lazar Kirchev as the listed maintainer of "beanutils" bundle. I assume that bundle (with its "private package") is just the way you found it?
Adding Chris as the listed maintainer of "collections" bundle. I assume you know of no reason not to "touch" the bundle so it get signed by current Eclipse certificate?
This is just a guess: I think the bundle org.apache.commons.beanutils should import package org.apache.commons.collections also and should not include any classes (privately) from that package in its own bundle jar. This is assuming the 4 classes it currently includes privately from org.apache.commons.collections are available from an exported package from the org.apache.commons.collections bundle.
I have 'touched' the collections bundle, I added a comment to the build.properties file, pointing back to this bug. Fixed in builds => I20130321031113 I did look up the original beanutils and it does have the stray collection classes there. The use the right works in some of their web pages ... but, guess the way the words are implemented is different than any of us would do it: = = = = = = = = Since the 1.7.0 release BeanUtils has distributed three jars: commons-beanutils.jar - contains everything commons-beanutils-core.jar - excludes Bean Collections classes commons-beanutils-bean-collections.jar - only Bean Collections classes The main commons-beanutils.jar has an optional dependency on Commons Collections = = = = = = = = = For those that actual use these, you might give feedback/open a bug on the project and see if they can come up with a better way of building/packaging. But, for now, I touched "collections" to bring it up to the latest cert. From a quick scan of what I happened to have loaded, I did not see any other bundles that "split" collection classes. (which would now newly be at risk of "not matching signatures"). But, hard to see from quick scan. I opened feature request 403976 to do more "unit testing" to make sure repo bundles are "well formed".
I've tested the new touched collection bundle in combination with beanutils in Tomcat. Now the server is starting up without any exceptions. Many thanks to all for solving this issue.
