N.B Can't see any chicken egg problem. If service doesn't resolve to same service api as client, then it isn't compatible. The client isn't interested in incompatible services, only those that are compatible This is just an artifact of the dependency resolution process.
No bundle indentifiers are necesary in the stream, the smart proxy ClassLoader decides visibility and delegation, not RMIClassLoader. You're attempting to do too many things with one class / object, there's a risk that this very powerful class could be leveraged by an attacker, best to break up the functionality. Also ServiceDiscoveryManager handles a lot of scenarios that occur with remote services, your class wont, there are thousands of lines of code. Have a look at SDM in JGDMS. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Peter <j...@zeus.net.au> Sent: 13/02/2017 11:15:27 pm To: dev@river.apache.org <dev@river.apache.org> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy So this object that you have with a locally installed class is tasked with authenticating the remote service, provisioning and resolving a bundle, deserializing the smart proxy and registering it with the OSGi service registrar in a readResolve or readObject method? How do you propose the connection from the client to the service established in order to enable this to occur? How do you prevent an attacker from choosing a different class to deserialize? Regards, Peter. Sent from my Samsung device Include original message ---- Original message ---- From: Michał Kłeczek <mic...@kleczek.org> Sent: 13/02/2017 10:07:28 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Comments inline. Peter wrote: > Mic, > > I'm attempting to get my head around your proposal: > > In the case of JERI, the InvocationHandler is part of the smart > proxy's serialized state. A number of smart proxy classes will need > to be unmarshalled before the UnmarshallingInvocationHandler is > deserialized. > > The smart proxy contains a reference to a dynamic proxy (which sun > called the bootstrap proxy) and the dynamic proxy contains a reference > to your UnmarshallingInvocationHandler. This means the smart proxy > must be unmarshalled first. > > How do you get access to UnmarshallingInvocationHandler without > unmarshalling the smart proxy first? No no - I am saying about wrapping the smart proxy inside another object. It can be either a dynamic proxy, or simply an object that implements "readResolve" returning the unmarshalled smart proxy. > > More comments inline below. > > On 13/02/2017 6:11 PM, Michał Kłeczek wrote: >> We are talking about the same thing. >> >> We are turning circles, Peter - all of this has been already discussed. >> >> 1. Yes - you need to resolve bundles in advance (in OSGi it is not >> possible to do otherwise anyway) > Agree. >> 2. You cannot decide upon the bundle chosen by the container to load >> the proxy class (the container does the resolution) > Disagree, nothing in the client depends on the proxy bundle, there's > no reason to provision a different version. >> 3. The runtime graph of object places additional constraints on the >> bundle resolution process (to what is specified in bundles' manifests). >> Since you do not have any way to pass these additional constraints to >> the container - the case is lost. > Disagree. The proxy bundle contains a manifest with requirements. > The stream has no knowledge of versioning, nor does it need to, there > are no additional constraints. If the service proxy dependencies > cannot be resolved, or it doesn't unmarshall, then it will not be > registered with the OSGi registry in the client, client code will not > discover it and the client will have no knowledge of it's existance > except for some logging. > This is totally backwards. That way no client is able to find any service because there is a chicken and egg problem - we do not know the proxy interfaces until the proxy's bundle is resolved. Understand that when you place a bundle identifier in the stream - it is equivalent to specifying a Require-Bundle constraint - nothing more nothing less. >> >> Additionally - to explain what I've said before about wrong level of >> abstraction: >> >> Your general idea is very similar to mine: have a special object >> (let's call it installer) that will install software prior to proxy >> unmarshalling. >> >> 1. For some reason unclear to me you want to constrain the way how >> this "installer object" is passed only via the route of >> ServiceRegistrar (as attributes) > > Disagree, I'm not proposing the service have any control over > installation at the client, other than the manifest in the proxy > bundle, nor am I proposing using service attributes, or the use of any > existing ServiceRegistar methods (see SafeServiceRegistrar link posted > earlier). If you think about it from the higher architectural view - there is no difference. It does not really matter what steps are made - important thing is that: a) you have a special object used to download code - this object is supposed to be of a class installed locally in advance b) the above object is used to create a ClassLoader that you will use it load the actual deserialized object's class It does not matter where the first object is taken from - be it "SafeServiceRegistrar", the stream itself, a JavaSpace or the Moon. Thanks, Michal
