I assigned it to me. I'll try to get back to it soon. regards,
Karl On Mon, Sep 29, 2014 at 2:23 PM, <dirk.rudo...@t-systems.com> wrote: > I created an issues: FELIX-4658. I hope the description and title are ok :) > > Unfortunately I'm not allowed to assign it to you but I am very interested > in your solution. > > Thanks so far, > Dirk > > > -----Ursprüngliche Nachricht----- > Von: Karl Pauls [mailto:karlpa...@gmail.com] > Gesendet: Montag, 29. September 2014 14:00 > An: users@felix.apache.org > Betreff: Re: Comprehension question about ProtectionDomain of a Bundle > > On Mon, Sep 29, 2014 at 1:34 PM, Felix Meschberger <fmesc...@adobe.com> > wrote: > > > > Hi > > > > Am 29.09.2014 um 13:13 schrieb Karl Pauls <karlpa...@gmail.com>: > > > > > On Mon, Sep 29, 2014 at 12:56 PM, <dirk.rudo...@t-systems.com> wrote: > > > > > >> What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is > > >> a URLHandler available for this? > > > > > > > > > No. > > > > > > > > >> So in this case JCE implemtation of OpenJDK will not be supported > > >> by Apache Felix (OSGI in general?) out of the box? > > >> > > > > > > If you choose to give a bundle location that doesn't work than yes, > > > you have a problem there. > > > > > > I suppose we could re-work the FakeURLStreamhandler to actually > > > serve up the content of the revision. So if the OpenJDK JCE > > > implementation would > at > > > least do the right thing with the code source url it might work > > > > I have the impression, that this might work, indeed. > > > The only way it might work (again, this is hacking a hack so ymmv) is to > override the JarUrl subsystem (and it will probably involve creating copies > of stuff all over the place to make it work with the reference: protocol - > which i wouldn't do initially). > > I can do it (please open a jira issue and assign it to me if you want > that) but keep in mind that it will be a very brittle solution to the > problem as it depends on the using library to do the right thing in regards > to URLs (which mostly will not happen) - but it should work for the OpenJdk > impl. > > regards, > > Karl > > > > > > > > but I > > > wouldn't be surprised if they don't (URLs and how to handle them are > > > a > mess > > > in java). > > > > +100 > > > > Regards > > Felix > > > > > > > > regards, > > > > > > Karl > > > > > > > > >> Regards, > > >> Dirk > > >> > > >> -----Ursprüngliche Nachricht----- > > >> Von: Karl Pauls [mailto:karlpa...@gmail.com] > > >> Gesendet: Montag, 29. September 2014 12:47 > > >> An: users@felix.apache.org > > >> Betreff: Re: Comprehension question about ProtectionDomain of a > > >> Bundle > > >> > > >> In the current Felix setup, though, this URL basically just is an > immutable > > >>> key referring to the abstract Bundle not to the concrete contents > > >>> of the Bundle. If we expect the CodeSource URL to actually refer > > >>> to the location from where classes are loaded, then the > > >>> BundleProtectionDomain should probably take the Content from the > > >>> BundleRevisionImpl to use as the basis for the CodeSource URL. In > > >>> this case, though, it is not relevant any longer what the string > > >>> for the > > >> bundle location actually is. > > >>> > > >> > > >> The BundleProtectionDomain does the correct thing. > > >> > > >> The problem is purely that some library assumes it can get the code > source > > >> of a protection domain and access it. That is wrong and a bad hack > > >> at > best > > >> but nothing we can paper over. > > >> Setting the bundle location as the code source is the correct thing > > >> to > do. > > >> If you want to work with that library (or others that do make the > > >> same > bad > > >> assumption) you can use a URLHandlers to make it work with your own > > >> namespace and you are good. This would only be a problem if you > > >> would > reuse > > >> bundle locations for bundles that are not identically which you > shouldn't > > >> do in the first place. > > >> > > >> regards, > > >> > > >> Karl > > >> > > >> > > >> WDYT ? > > >>> > > >>> Regards > > >>> Felix > > >>> > > >>> Am 29.09.2014 um 11:27 schrieb <dirk.rudo...@t-systems.com> < > > >>> dirk.rudo...@t-systems.com>: > > >>> > > >>>> Thanks so far for your explanations. > > >>>> > > >>>> So Am I right that each provider that installs bundles in Felix > > >>>> using a > > >>> custom bundle location (as Sling OSGI installer does) has to > > >>> provide a URL handler that is able to resolve to the proper jar file? > > >>>> > > >>>> Think about the following cases: > > >>>> > > >>>> - Install a bundle using OSGI installer, the Bundle-Location will > > >>>> be > > >>> jcrinstall:/apps/path/install/bundle-1.0.0.jar for example > > >>>> - Update the bundle with the same symbolic name but another > > >>>> version > > >>> using the webconsole, the Bundle-Location will be the same > > >>>> > > >>>> or > > >>>> > > >>>> - Install a bundle using OSGI installer, the Bundle-Location will > > >>>> be > > >>> jcrinstall:/apps/path/install/bundle-1.0.0.jar for example > > >>>> - Update the bundle with the same symbolic name by removing > > >>> /apps/path/install/bundle-1.0.0.jar and uploading the new version > > >>> to /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will > > >>> also be the same > > >>>> > > >>>> Due to this the I think the location of the CodeSource should > > >>>> always > > >>> point to the cache jar (the one the actual class is loaded from, > > >>> think about embedded dependency). Otherwise it would be hard to > > >>> implement a proper URLStreamHandlerService. > > >>>> > > >>>> For the JarURLConnection: Is the cached file transient? > > >>>> > > >>>> Cheers, > > >>>> Dirk > > >>>> > > >>>> -----Ursprüngliche Nachricht----- > > >>>> Von: Karl Pauls [mailto:karlpa...@gmail.com] > > >>>> Gesendet: Montag, 29. September 2014 10:23 > > >>>> An: users@felix.apache.org > > >>>> Betreff: Re: Comprehension question about ProtectionDomain of a > > >>>> Bundle > > >>>> > > >>>> 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.co > > >>>>> m> > > >>>>> 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 > > >>>> > > >>> B > KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > > >>> CB [ X ܚX K K[XZ[ \ \ ][ X ܚX P [ ^ \ X K ܙ B ܈ Y ] > [ۘ[ > > >> [X[ > > >>> K[XZ[ \ \ Z [ [ ^ \ X K ܙ B > > >>> > > >>> > > >> > > >> > > >> -- > > >> Karl Pauls > > >> karlpa...@gmail.com > > >> http://twitter.com/karlpauls > > >> http://www.linkedin.com/in/karlpauls > > >> https://profiles.google.com/karlpauls > > >> > > >> ------------------------------------------------------------------- > > >> -- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > >> For additional commands, e-mail: users-h...@felix.apache.org > > >> > > > > > > > > > > > > -- > > > Karl Pauls > > > karlpa...@gmail.com > > > http://twitter.com/karlpauls > > > http://www.linkedin.com/in/karlpauls > > > https://profiles.google.com/karlpauls > > > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
