Hi Dirk, we are using bouncycastle as jce provider in our application setup based on > AEM (Apache Sling) and I got an error during jar verification. (Something > with MalformedURLException). >
Yeah, irrc they do assume that the code source of a protection domain is a valid url which isn't necessarily the case for OSGi bundles (I'd argue they shouldn't but oh well). > For my use case I fixed the issue by implementing a > URLStreamHandlerService providing a URLConnection to the bundle location > but during my work on this I thought about the topic more in general. > I guess that it is probably ok to handle the situation like this assuming you can provide the handler. > As the comment in BundleProtectionDomain.java:38 says the CodeSource of a > BundleProtectionDomain should be based on the revision of the bundle not > the bundle itself. (for me the bundle location is > "jcrinstall:/a/path/to/the/bundle.jar") > You should be able to ignore this comment. The BundleProtectionDomain does indeed provide the bundle revision. It just does get the revision in a stupid way - hence, the comment to remind me that I should figure out a better (i.e., less indirect) way to provide the revision to it. > Is there any reason why the bundle location is used here and not the > file:///<file:///\\> URL of the revision located in the cache instead? > Well, the idea is that you base your security policies on the code source url. That concept would be pretty much meaningless if the code source would be the cached jar. Regardless, the cache implementation (and its layout) is mostly undefined by the spec - the code source is the Bundle-Location URL (consider, for example, the JarURLConnection of the ire: it will cache the jar file on disc as a JarFile but the url will still be the one of the source for the code source). > I mentioned that unfortunatly the JceSecurity implementation has a > WeakHashMap<Class,URL> that holds the URL to the location of the > CodeSource. So I assume that it might be possible that the worng CodeSource > location can be returned there when the cache points to a old revision > location after a bundle update without garbage collection of the old > revision. Am I right? > No. The Class object is unique based on its class loader so you will get the code source URL that was associated with the bundle revision that this class has been loaded from. As long as they key the map by an actual Class object and get the URL from the code source of the BundleProtectionDomain of that class object you should be good. regards, Karl > Kind Regards, > > Dirk Rudolph > > > T-Systems Multimedia Solutions GmbH > Organisationseinheit CCS > Dirk Rudolph > Software-Entwicklung, OCJP > Hausanschrift: Riesaer Straße 5, 01129 Dresden > Postanschrift: Postfach 10 02 24, 01072 Dresden > +49 351 2820-5363 (Tel) > E-Mail: dirk.rudo...@t-systems.com<mailto:mdirk.rudo...@t-systems-mms.com> > Internet: http://www.t-systems-mms.com<http://www.t-systems-mms.de/> > > T-Systems Multimedia Solutions GmbH > Aufsichtsrat: Thilo Kusch (Vorsitzender) > Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner > Handelsregister: Amtsgericht Dresden HRB 11433 > Sitz der Gesellschaft: Dresden > Ust-IdNr.: DE 811 807 949 > > > -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
