> On Jan 5, 2016, at 10:51 PM, Peter <j...@zeus.net.au> wrote: > > <snip> > > ProxyPreparer in its current form is broken. > > Proxy preparation assumed that both the java sandbox and serialization are > secure, code is downloaded, static class initialisers and readObject methods > are executed on untrusted foreign code, you're POWNED by the attacker, only > then are invocation constraints applied, then the proxy provides the > bootstrap proxy, the service is authenticated, the bootstrap proxy provides > the TrustVerifier via a remote call and the TrustVerifier checks if the proxy > can be trusted, and finally method constraints are applied, oops, how can > that possibly work?!
Perhaps I’m misunderstanding something - As I understand it, a proxy is deserialized into a new, empty classloader - i.e. it begins with no permissions. Permissions are only granted by the ProxyPrepare.prepareProxy(…) method after trust verification is performed. Am I wrong about that? > > <snip> > > The broken concept of TrustVerifier is no longer required, the process is > simplified and much more secure. > > All of the above becomes a ProxyVerifier and configuration concern; client > code doesn't need to be involved. > It already is a ProxyPreparer and configuration concern. The TrustVerifiers are automatically configured through manifest entries in the client library ‘jar’ file. All the client needs to do is instantiate a ProxyPreparer and call it on the proxy before using it. In most cases, BasicProxyPreparer is fine, since it uses the manifest-configured TrustVerifiers (which would also be shipped in the client library). Alternately, the service provider could provide an alternate ProxyPreparer implementation. What’s the problem, exactly, that this more complex lookup procedure solves? > This will require some backward compatible revisions to the lookup service, > that we'll need to discuss before implementing. > > All this should be up for constructive discussion, when the time comes, lets > discuss each argument concisely, park some for later discussion, so we can > resolve any differences we have and make progress. > > We also need to address httpmd insecurity, discuss whether to upgrade it, or > deprecate and replace with signed jar codebases. > > The network is changing, we can't cling to ipv4 and NAT firewalls to provide > security. I wish you’d stop making these unsupported straw-man assertions. When has anyone ever said anything about clinging to ipv4? As far as NAT firewalls, the design is clear - Jini doesn’t cross NAT firewalls. > > Activation removal has been voted on for 2.2, not 3.0, this is an > understandable decision from a maintence reduction persspective, considering > that 2.2 is an LTS and completely separate branch, that duplicates work. > Personally, I voted to remove it entirely - we just decided to remove it in the next iteration of the 3.0 branch. > It makes much less sense in 3.0, I've already performed the maintenance > required on Phoenix, I'm reluctant to throw that away just yet, perhaps it > still makes sense to remove support for jrmp activation, which will simplify > phoenix and make it portable to other jvm's, but why not retain jeri > activation, it's portable? Sun jrmp activation was intended as a compatible > uprade away from rmid. > > Users may not have noticed the recent vote to remove activation from 2.2, > some felt quite strongly about this in the past: > That was discussed and voted on. Do you have a problem accepting the community’s decision? I’ll say it again, Peter - River on the Internet is not going to happen. Stop trying to make it happen. Roy is right about this - HTTP is all the protocol you’ll ever need for the Internet. We’ve talked about this several times, and each time, the PMC has said “no”. Fork the project and find a new community if that’s what you’re determined to work on. Greg Trasuk
