Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Message-ID: <57F8E7FE.1040207@zeus.net.au>
Date: Sat, 08 Oct 2016 22:35:10 +1000
From: Peter <jini@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Future of River
References: <077a640e8c46a426892bb5e06cc160fa@org.tizen.email> <0d9a1a8b-ad30-0b29-e919-291b59868adf@acm.org>
In-Reply-To: <0d9a1a8b-ad30-0b29-e919-291b59868adf@acm.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Sat, 08 Oct 2016 12:35:29 -0000

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.
>>>>
>>>>
>>
>>
>>
>