river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Future of River
Date Tue, 11 Oct 2016 02:46:38 GMT
While we're on this subject, we need to consider that support for jrmp and activation were
removed in River 2.2.3.  These are still present in River 3.0.0, we should consider deprecating
them for the next release.

MarshalledObject uses the jrmp protocol, a number of classes and methods in the Jini standards
contain it, we should consider adding new methods (including interface default methods) using
MarshalledInstance instead and deprecate the existing methods.

MarshalledObject is final, MarshalledInstance can be subclassed.

In addition, I'd like to propose we make MarshalledInstance extensible, so subclasses can
support different serialization protocols easily, thus making River's api also extensible.
For instance someone may wish to use a more compact serialization protocol when implementing
JavaSpaces to save memory or increase scalability.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Peter <jini@zeus.net.au>
Sent: 09/10/2016 12:59:41 pm
To: dev@river.apache.org
Subject: Re: Future of River

Patricia, you may be right, it's time to grow the project with external  
interest, but we'll need to work on the website and documentation, or  
we'll lose them.  I'm hoping to rengage our existing developers at this  

My vision is pretty similar to the vision that the original Jini team  
had, but with the lessons of time and hindsight. 

To dynamically discover and search software and devices and to be able  
to interact with them dynamically using a downloaded service UI or  
service api. 

We know that River's very useful for building large systems, but we also  
know that ClassLoading and versioning create problems, refer to Orbitz.   
We know that Dennis' work with Rio solves some of these problems with  
Maven and Rio also solves other problems with quality of service.  We  
also know that River / Jini is still being used today in projects such  
as Blazegraph for scale out (thank you Bryan). 

Jini sort of was the first IoT framework, but the underlying IPv4  
network requires configuration to support multicast, requires firewalls  
and NAT for security and doesn't auto configure itself (IPv6 can and  
does) and small devices don't run Java SE jvm, due to battery power  
limitations, these devices use C. 

We find ourselves in fortunate times, there's IoT, which is being  
enabled by IPv6's restoration of end to end connectivity.  There's Java  
Serialization security vulnerabilities and RMI in the enterprise space.   
The Java team will not take all necessary steps required to secure  
serialization and many other serialization schemes are subject to  
similar vulnerabilities.  The simple answer is to use secure sockets, to  
protect serialization and RMI, but it doesn't solve the problem of  
validating data, so you're limited to trusted endpoints only with RMI  
and Java serialization.  We can offer a solution to that problem. 

People may have forgotten the security benefits of type safety and the  
absence of memory errors due to buffer overruns as these are being  
overshadowed by serialization and applet vulnerabilties.  The former due  
to a lack of input validation and the latter due to vulnerabilities in  
the java sandbox. 

River does need to be easier to use, that doesn't mean throwing out  
what's been done and starting again, but it does mean building tools to  
simplify use, such as tools to assist setting up policy files and  
certificates etc, or a modular build, or graphical tools to display more  
information about jini services.  It doesn't mean we can ignore the  
underlying problems in the code either though, such as security issues  
or network connectivity. 

I think by demonstrating that we can solve some of the most difficult  
problems (as others have done eg Dennis Reedy and Gregg Wonderly), we  
provide hope that these problems can be solved.  If a problem that  
discouraged the adoption of Jini can be solved then that makes River  
more useable.  We have many years of mail list history that demonstrate  
the problems, the divide between the original goal of Jini and the  
actual experiences users had. 





On 8/10/2016 10:58 PM, Patricia Shanahan wrote: 
> To get the feedback you need, you have to reach a far wider audience 

> than dev@ 
> Including the user@ list is necessary, but far from sufficient. 
> You need to identify the potential users for your vision, find out  
> where they discuss things, and meet with them there. Is there a gap  
> that a reworked River would fill well? 
> Think in terms of a business plan. You will be asking people to invest 

> time and energy, not money, but it is still an investment that can  
> only be motivated by an unmet need. 
> On 10/8/2016 5:35 AM, Peter wrote: 
>> Thanks Patricia. 
>> It would be nice if we could hear a little about what people want for

>> River going forward. 
>> Regards, 
>> Peter. 
>> On 7/10/2016 5:08 PM, Patricia Shanahan wrote: 
>>> This message is to change the subject line. These comments are far too

>>> important to be mistaken for being part of wrapping up the 3.0 release.

>>> On 10/6/2016 10:57 PM, Peter wrote: 
>>>> To answer my own question, a list of items that require attention:

>>>> 1. Modular build. 
>>>> 2. Improved IPv6 support 
>>>> 3. Update to TLS v1.2 and update constraints. 
>>>> 4. Investigate Maven codebase provisioning, do we need to use the

>>>> Maven ClassWorlds ClassLoaders, what about proxy identity? 
>>>> 5. Fix security. 
>>>> 6. Update website. 
>>>> 7. Development guide for River devs. 
>>>> 8. Redundancy? 
>>>> 9. Update user docs, perhaps update Jan Newmarch's book? 
>>>> Cheers, 
>>>> Peter. 
>>>> Sent from my Samsung device. 
>>>>   Include original message 
>>>> ---- Original message ---- 
>>>> From: Peter <jini@zeus.net.au> 
>>>> Sent: 07/10/2016 12:25:01 pm 
>>>> To: dev@river.apache.org 
>>>> Subject: Re: [VOTE] Release Apache River 3.0.0 
>>>> The question is of course where to next? 
>>>> As people are aware I've been working on addressing security issues 

>>>> and 
>>>> how to make River better and more secure.  I've been working on this

>>>> outside the project because my attempts to discuss it caused heated

>>>> arguments.  I figured that if I could demonstrate a working example 

>>>> that 
>>>> people could try out, it could allevieate any misunderstandings 

>>>> that may 
>>>> have developed due to language or culture differences. 
>>>> River's approach to security (a result of the Jini Davis project) is

>>>> quite complex and contains a flaw borne out of two limitations around

>>>> the time it was developed: 
>>>>    1. The assumption that the Java sandbox and java serialization was

>>>>       secure (we know today this isn't the case). 
>>>>    2. Interfaces cannot be changed (no longer true with java 8), in 

>>>> this 
>>>>       case ServiceRegistrar was designed prior to the later added on

>>>>       security features. 
>>>> What's wrong with River's approach? 
>>>> Answer:  It validates and authenticates after downloading code and

>>>> deserializing untrusted data, using the proxy trust framework, by 

>>>> asking 
>>>> an already downloaded and deserialized service proxy for a bootstrap

>>>> proxy, the client code then uses the boostrap proxy to determine if 

>>>> the 
>>>> service proxy can be trusted.  Too little too late.  Why not instead

>>>> recieve a bootstrap proxy, deserialized using input validation, 

>>>> without 
>>>> code download, authenticate the remote endpoint, then ask the 

>>>> bootstrap 
>>>> proxy for the service proxy? 
>>>> The trouble with the existing approach today is an attacker has

>>>> opportunity to take control of a computer using deserialization alone.

>>>> For those who think a network firewall is sufficient protection and 

>>>> the 
>>>> flawed security design isn't an issue on local networks, even in air

>>>> gapped networks, an attacker can leave a USB key in a car park

>>>> containing malware that looks for network transmissions that contain

>>>> java serialized data, hoping that someone will pick it up and plug it

>>>> into their pc, the malware will send serial data containing a gadget

>>>> attack to a listening network port that accepts java serial data and

>>>> take over the infected computer. 
>>>> All network communications using standard java serialization must be

>>>> both authenticated and encrypted, prior to reading in any data to 

>>>> ensure 
>>>> that the data is trusted. 
>>>> I think we can all accept that these vulnerabilities exist and 

>>>> googling 
>>>> java serialization gadget attacks should convince even the most 

>>>> doubtful 
>>>> sceptic. 
>>>> Relevant links: 
>>>> https://www.apache.org/dev/committers.html#apache-way 
>>>> http://www.apache.org/security/committers.html 
>>>> I would like the opportunity to explain more, and go through working

>>>> examples of solutions before we start arguing about whether we should

>>>> solve these problems.  Anyone reading the Apache Way will realise that

>>>> security is a mandatory feature of Apache Software and therefore we

>>>> should consider how we should fix existing security issues in River 

>>>> and 
>>>> while doing so, take the opportunity to make security simpler to

>>>> implement.  Arguments should not be about the relevance of security

>>>> issues, but rather the suitablility of solutions. 
>>>> Regards, 
>>>> Peter. 
>>>> On 6/10/2016 2:04 PM, Bryan Thompson wrote: 
>>>>>  Excellent.  A great step. 
>>>>>  Bryan 
>>>>>  On Wednesday, October 5, 2016, Peter 
>>>>> Firmstone<peter.firmstone@zeus.net.au> 
>>>>>  wrote: 
>>>>>>  Results: 
>>>>>>  3 binding votes 
>>>>>>  1 non binding 
>>>>>>  None against. 
>>>>>>  The artifacts have been published, we need to wait 24 hours before

>>>>>>  announcing. 
>>>>>>  Regards, 
>>>>>>  Peter. 
>>>>>>  Sent from my Samsung device. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message