Re: deserialization remote invocation strategy

I can't make any guarantee that it is secure, but the more people review it, the more likelihood bugs and flaws will be identified. I'm especially interested in security researchers checking it out if they're interested. Cheers, Peter. Sent from my Samsung device.     Include original

Re: deserialization remote invocation strategy

The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. It works the other way around - before I decide to use it - I have to understand how it works. Even more so if we are talking about security. That is why

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

A code downloading object is of course possible.  If you implement it, I can review it from a security perspective if you like. Cheers, Peter. Sent from my Samsung device.     Include original message Original message From: Michał Kłeczek Sent: 15/02/2017

Re: deserialization remote invocation strategy

Ok, Will see what I can do over the weekend. For users already familiar with River, there's not much new as it's mostly abstracted behind ServiceDiscoveryManager, LookupCache' ProxyPreparer and ServiceItemFilter. The non trivial part is implementing AtomicSerial. An introduction to

Re: deserialization remote invocation strategy

Reviewing just the source code without any high level overview and explanation how and why it is implemented in a particular way is difficult (if possible at all). That is why it would be really helpful if the questions asked were answered. Not only researchers are interested - also potential

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 work lol!  I wouldn't agree with me either! My work: 1. new secure discovery protocols that include registrar codebase url and signers. 2. authenticate lookup service during disco, grant minimal

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

N.B. Clarification on item 4. This is for cases when we really want to lock down the registrar. Once the token has been confirmed as trusted and an instance of java.lang.reflect.Proxy, it can be marshalled and unmarshalled into the Client's ClassLoader, the client uses it to authenicate the

Re: deserialization remote invocation strategy

Thanks Pat, I'd appreciate that.  I've documentation, but there's no single document at present.  Do you think a draft revision of the Jini specifications documenting the additions would be sufficient? Regards, Peter. Sent from my Samsung device.     Include original message Original