Mic,
I've taken the liberty to copy paste your questions into the list below
(my apologies if I've missed some), my answers to your questions follow.
I'll apologise in advance, as I don't have time to answer more follow up
questions, perhaps others on the list might be able to assist.
Regar
ll
arguments / assumptions. Sometimes the right questions are more important
than answers.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 15/02/2017 12:58:55 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi
ght questions are more
>> important than answers.
>>
>> Regards,
>>
>> Peter.
>>
>> Sent from my Samsung device.
>> Include original message
>> ---- Original message ----
>> From: Peter
>> Sent: 15/02/2017 12:58:55 pm
>> To
@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Miscommunication... as usual :D
Anyway - I was really interested why you find the need for the bootstrap
proxy to be necesarilly a dynamic proxy
(since you seemed to find it very important from the
In fact I encourage you to do so as this can
only serve to increase understanding.
Cheers,
Peter
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 05:00:14 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was:
ginal message
Original message
From: Peter
Sent: 15/02/2017 07:01:06 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Oh I thought it was part of your SmartProxyWrapper?
Who'd have thought you were talking about my wo
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 05:00:14 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
They are valid questions and you haven't answer
roxy be loaded by the codebase ClassLoader?
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 06:20:37 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
s
oxy be loaded by the codebase ClassLoader?
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 06:20:37 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
str
gards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 06:20:37 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So I've given it some thought an
e
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:27:09 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote
invocation strategy
See below.
Peter wrote:
Using one of the secure discovery providers with authentication
and input validation
So I've given it some thought and the only explanation I can come up
with is:
1. To create an instance of the bootstrap proxy you need the codebase
annotation.
2. Codebase annotation is needed because you want the bootstrap proxy's
class to be
defined in the proper codebase ClassLoader
3. Sin
Let me dig some deeper. Comments inline.
Peter wrote:
Yes the dynamic proxy's are 100% local code. Remember dynamic proxy's don't
have codebase s. :)
Of course they do - look at PreferredClassProvider - the dynamic proxy
class is defined by the codebase loader!
Being a dynamic proxy does no
nvestigate further.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 14/02/2017 09:34:01 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
There's a new constra
It seems like I am missing the high level view on the architecture of
your software.
Would it be possible for you to write one?
Peter wrote:
There's a new constraint AtomicInputValidation that jeri uses to prevent
standard serialization being used.
Reggie has been granted DownloadPermission a
ry.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 07:39:52 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Comments inline.
Peter wrote:
Comments inline.
Peter wrote:
Some of your assumptions around forbidding code downloading are incorrect,
which means the other assumptions that rely upon it are also wrong.
Which assumptions?
I know about DownloadPermissions. And while using RequireDlPermProvider
closes the security vulnerabi
ent: 14/02/2017 03:43:39 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Wouldn't it be easier if you simply forbid code downloading during
unmarshalling as in SmartProxyWrapper I've shown in another message?
Then u
Wouldn't it be easier if you simply forbid code downloading during
unmarshalling as in SmartProxyWrapper I've shown in another message?
Then u use the unmarshalled bootstrap object to securely download the
real proxy using existing Jeri implementation.
Then you do not need any advanced discovery
All of them?
Thanks,
Michal
>
>
> Sent from my Samsung device.
>
>Include original message
> Original message
> From: Michał Kłeczek
> Sent: 14/02/2017 01:27:09 am
> To: dev@river.apache.org
> Subject: Re: OSGi NP Complete Was: OSGi - deserializat
some defensive programming?
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:42:23 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Both ways have
@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
It is as simple as:
interface ServiceProxyDownloader extends Remote, RemoteMethodControl {
Object downloadServiceProxy() throws RemoteException;
}
//this class is local to the client - to make
om my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:45:43 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Peter wrote:
> The codebase is signed and download permission
Sent: 14/02/2017 01:13:04 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So your SaveUnmarshallingProxy can do input validation fist as well,
can't it?
BTW - how does the client unmarshalls SafeServiceRegistrar pro
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:27:09 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
See below.
Peter wrote:
Using one of the secure discovery providers with authenti
think we can do much more to support OSGi.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:05:54 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invoc
- deserialization remote invocation
strategy
See below.
Peter wrote:
> Using one of the secure discovery providers with authentication and input
>validation. Download and deserialization permissions are granted dynamically
>just after authentication, but before download.
But now you j
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:21:46 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So if the CodeDownloadingSmartProxyWrapper implements AtomicSerial then
it is fine?
Cool - lets do that.
Thanks
Sent from my Samsung device
>
>Include original message
> Original message
> From: Michał Kłeczek
> Sent: 14/02/2017 12:39:40 am
> To: dev@river.apache.org
> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
>strategy
&g
See below.
Peter wrote:
Using one of the secure discovery providers with authentication and input
validation. Download and deserialization permissions are granted dynamically
just after authentication, but before download.
But now you just moved trust decisions to SafeServiceRegistrar
implem
@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So your SaveUnmarshallingProxy can do input validation fist as well,
can't it?
BTW - how does the client unmarshalls SafeServiceRegistrar proxy in a
secure way?
Thanks,
Michal
Peter wrote:
,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:13:04 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So your SaveUnmarshallingProxy can do input
first.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:42:43 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
I fail to understand how you are
Complete Was: OSGi - deserialization remote invocation
strategy
I fail to understand how you are more vulnerable because of trusted
local class that securely downloads code on behalf of a service.
And how in terms of security it is different from your
SecureServiceRegistrar.
Thanks,
Michal
--
From: Michał Kłeczek
Sent: 14/02/2017 12:39:40 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
But what if the client has MULTIPLE clients - each with its own exact
API version?
OSGi handles this case just fine with service tracker
ution solve this problem?
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:39:40 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
But wh
local class with a
readResolve method?
Sorry.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:14:41 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invoc
ssage
From: Michał Kłeczek
Sent: 14/02/2017 12:24:58 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Peter wrote:
There a multiple remote services, if one client cant obtain a service because
there is also a later version inst
Original message
From: Peter
Sent: 14/02/2017 12:33:54 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
You can however for each service api package version, it's all in the smart
proxy bundle manifest.
You are bou
Gi NP Complete Was: OSGi - deserialization remote invocation
strategy
Peter wrote:
> In jgdms I've enabled support for https unicast lookup in LookupLocator this
>establishes a connection to a Registrar only, not any service. This
>functionality doesn't exist in River.
gards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:24:58 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Peter wrote:
> There a multipl
Peter wrote:
There a multiple remote services, if one client cant obtain a service because
there is also a later version installed then you need a service that doesn't
import the later version. You can still supply another service to cater.
This does not scale because you would have to have o
evice.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 13/02/2017 11:59:34 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Comments inline.
Peter wrote:
N.B Can't
Peter wrote:
In jgdms I've enabled support for https unicast lookup in LookupLocator this
establishes a connection to a Registrar only, not any service. This
functionality doesn't exist in River.
How do you propose establishing a connection using one of these endpoints?
I am not sure I unde
nt from my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 14/02/2017 12:00:02 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
KerberosEnpoint?
Htt
SGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Sorry, I'm trying to find out the meaning of the current subject line.
I'm not sure when it changed to "OSGi MP Complete".
On 2/12/2017 10:50 PM, Michał Kłeczek wrote:
Sorry, NP Completness of what?
I
ice.
Include original message
Original message
From: Patricia Shanahan
Sent: 13/02/2017 11:27:27 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Sorry, I'm trying to find out the meaning of the current subject line.
I
pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
1. The connection can be done using normal (secure) Jeri.
We do not have to verify the installer object since its classes were loaded
locally and (by definition) are trusted.
2 Th
Comments inline.
Peter wrote:
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 resoluti
o.)"
Sent: 13/02/2017 11:34:45 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
1. The connection can be done using normal (secure) Jeri.
We do not have to verify the installer object since its classes were loaded
locally and
Was: OSGi - deserialization remote invocation
strategy
1. The connection can be done using normal (secure) Jeri.
We do not have to verify the installer object since its classes were loaded
locally and (by definition) are trusted.
2 The attacker cannot instantiate any non-local class. That is the w
message
From: Peter
Sent: 13/02/2017 11:15:27 pm
To: 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 reso
choosing a different class to deserialize?
Regards,
Peter.
Sent from my Samsung device
Include original message
Original message
From: Michał Kłeczek
Sent: 13/02/2017 10:07:28 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
Sorry, I'm trying to find out the meaning of the current subject line.
I'm not sure when it changed to "OSGi MP Complete".
On 2/12/2017 10:50 PM, Michał Kłeczek wrote:
Sorry, NP Completness of what?
I have been the first to mention NP hardness of constraint satisfaction
problem
but I am not sur
/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
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
deseria
To be fair, my position changed somewhat after Nic's email and some
further research, it may of course develop further with understanding
and experimentation.
Cheers,
Peter.
On 13/02/2017 7:52 PM, Peter wrote:
Mic,
I'm attempting to get my head around your proposal:
In the case of JERI, th
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
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)
2. You cannot decide upon the bundle chosen by the container to load the
proxy class
Also see the OSGi Enterprise specification, v6, Chapter 136, page 691,
there's some discussion about the NP-complete nature of dependency
resolution there as well.
https://www.osgi.org/developer/downloads/release-6/release-6-download/
On 13/02/2017 5:19 PM, Peter wrote:
OSGi Dependency resolu
OSGi Dependency resolution is.
http://underlap.blogspot.com.au/2010/02/osgi-resolution-is-np-complete-so-what.html
Which means if we want to support an OSGi environment properly, we may
need some time to resolve the dependencies for a smart proxy, before
deserializing the proxy, rather than do
Sorry, NP Completness of what?
I have been the first to mention NP hardness of constraint satisfaction
problem
but I am not sure if this is what you are asking about.
Thanks,
Michal
Patricia Shanahan wrote:
Are you literally claiming NP Completeness, or just using that as an
analogy for reall
Are you literally claiming NP Completeness, or just using that as an
analogy for really, really difficult?
On 2/11/2017 1:23 PM, Michał Kłeczek wrote:
I am sorry but I think that to solve various issues we need to make sure
fundamentals are right:
1. There is NO such a thing as "reflective non
n, it requires a
codebase.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 12/02/2017 08:42:23 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Thanks Michal,
Thanks Michal,
See inline below.
On 12/02/2017 7:23 AM, Michał Kłeczek wrote:
I am sorry but I think that to solve various issues we need to make
sure fundamentals are right:
1. There is NO such a thing as "reflective non-smart" proxy - EVERY
proxy is "smart" (even if it is "reflective") - t
I am sorry but I think that to solve various issues we need to make sure
fundamentals are right:
1. There is NO such a thing as "reflective non-smart" proxy - EVERY
proxy is "smart" (even if it is "reflective") - there is an
InvocationHandler down there, isn't there?
2. Solving this on service
In a word, ServiceDiscoveryManager
ServiceDiscoveryManager is the solution.
ServiceDiscoveryManager performs discovery and looks up services from
registrars based on filters. ServiceDiscoveryManager then performs
local filtering. This allows time for proxy bundles to be installed,
resolve,
Thanks Nic,
It looks like OSGi is generating a lot of interest. I'm spending a lot
of time respoding to discussions, which is important, but I'd also like
to get the the existing test suite working with the new JGDMS OGSi
Bundles, so will have to excuse myself as I'm still in the learning
u
> On Feb 7, 2017, at 8:56 AM, Michał Kłeczek (XPro Sp. z o. o.)
> wrote:
>
> Comments inline
>
> Niclas Hedhman wrote:
>> 4. For Server(osgi)+Client(osgi), number of options goes up. In this space,
>> Paremus has a lot of experience, and perhaps willing to share a bit,
>> without compromising
Maybe there are some misunderstanding somewhere... see below;
On Wed, Feb 8, 2017 at 3:35 AM, Peter wrote:
> I'm currently only considering OSGi server -> OSGi client. Mick's
investigating all four options.
Ok, makes it a lot easier for me to follow.
> Not expecting the client calling bundle t
Correct in the second instance.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 08/02/2017 09:24:21 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
So in this case there is no
vocation handler and marshal streams) .
>
> Cheers,
>
> Peter.
> Sent from my Samsung device.
>
> Include original message
> Original message
> From: Michał Kłeczek
> Sent: 08/02/2017 06:51:55 am
> To: dev@river.apache.org
> Subject: Re: OSGi
In other words would work where MarshalInputStream is used.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 08/02/2017 06:51:55 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
I think
h its own
jeri endpoint and invocation handler and marshal streams) .
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 08/02/2017 06:51:55 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocat
gt; Cheers,
> >
> > Peter.
> >
> > Sent from my Samsung device.
> >
> >Include original message
> > Original message
> > From: "Michał Kłeczek (XPro Sp z o. o.)"
> > Sent: 08/02/2017 05:51:07 am
> > To: dev@river.apache.org
om: Michał Kłeczek
Sent: 08/02/2017 06:07:19 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
Hmm.. I see.
So your solution explicitly only handles cases of looking up a service
in the ServiceRegistrar.
How about smart RemoteEventListeners? Th
Clarification inline.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 08/02/2017 05:35:57 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
Hi Nic,
I'm currently only considering OSGi s
om my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 08/02/2017 05:51:07 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
So I must have misunderstood the part about smart proxies b
on proxy instead
of MarshalledIstance.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 08/02/2017 05:51:07 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invoc
ude original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 08/02/2017 12:28:50 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
Are you proposing to provide a bootstrap object that will download some
m
Peter.
Sent from my Samsung device.
Include original message
---- Original message
From: Niclas Hedhman
Sent: 08/02/2017 12:32:35 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
TL;DR
1. It sounds awfully complex, because my gut says that it is n
No, no bootstrap objects.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 08/02/2017 12:28:50 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation str
Comments inline
Niclas Hedhman wrote:
4. For Server(osgi)+Client(osgi), number of options goes up. In this space,
Paremus has a lot of experience, and perhaps willing to share a bit,
without compromising the secret sauce? Either way, Michal's talk about
"wiring" becomes important and that wiring
Are you proposing to provide a bootstrap object that will download some
meta information prior to class resolution?
How does it differ from simply changing annotations to be those
"bootstrap objects" instead of Strings?
Thanks,
Michal
Peter wrote:
Proposed JERI OSGi class loading strategy d
TL;DR
1. It sounds awfully complex, because my gut says that it is not a solvable
problem, especially since I don't see 4 distinct cases;
Server(osgi)+Client(osgi), Server(osgi)+Client(plain),
Server(plain)+Client(osgi) and Server(plain)+Client(plain), where the last
one is what we currently have.
Proposed JERI OSGi class loading strategy during deserialization.
Record caller context - this is the default bundle at the beginning of
the stack. It is obtained by the InvocationHandler on the
client side. The InvocationDispatcher on the server side has the
calling context of the Remote
imp
86 matches
Mail list logo
