Development Environment

[Peter Firmstone <pe...@zeus.net.au>]

Thanks Bryan,

On 10/11/2020 8:18 AM, Bryan Thompson wrote:
> +1. It sounds like this addresses concerns for moving to GitHub.
>
> Question: will this help people to find the right development environment
> or do we need to do something more to enable that?

It will help, however to achieve that goal, we need to document the new 
practices of modular development with River, not only have the build 
tools changed, but development has too, for example exporting services; 
the old way a service was exported was during construction, which lets 
the service's "this" reference to escape before the constructor has 
completed and any final fields are frozen.  There are a lot of Jini 
books out there, where the standard way of doing things contain bad 
practices.  While it's been discussed on this list, there are no easily 
accessible documents containing best practices.

We also need to show people how to code their services, so that should 
they wish to secure them at a later date, they only need change their 
configuration, this is actually very simple, but I don't think many 
people are aware of the details.

When people think of secure services they remember the complexity of 
proxy trust, which turns out, thanks to the insecurity of Java 
Serialization (which thankfully is now clearly true and unquestionable), 
is both completely useless and unnecessary.   To be fair, the developers 
of Jini, who also created Java Serialization must have assumed that it 
would be maintained in such a way to address security issues as they arose.

Of course River is not yet secure, but the security issues have been 
solved now outside the project in ways that also reduce complexity and 
improve performance, which can be used by River as a prototype to create 
an even better implementation.

Without diverging too far down a tangent, the last time I had a 
discussion with Java's developers, they were not ready to give up 
deserialization of object graphs with circular references, which 
prevents validation of invariant's during deserialization prior to 
object construction, this discussion was prior to the current serial 
filters implementation.  An example of an object graph that contains a 
circular reference is Throwable, it contains a reference to itself.  But 
I've found it possible to wire up circular references, without requiring 
the serialization framework to support it.   The advantage that Java 
serialization has over other frameworks, is the transmission of object 
graphs, that is objects, not just primitive types, and that is the basis 
of River.  As a result people are turning to serialization frameworks 
that only support serialization of primitive values.  However 
serialization of object graphs can be secure, if we give up transmission 
of circular references, leaving it up to the objects themselves to wire 
up the circular links afterwards.  But for now, Java serialization is 
best thought of as a tool that allows the originator of the serialized 
data to create any object they like using any parameters they like.

The way I solved Java serialization's known insecurities was to take the 
serialization framework from Apache Harmony, and re-implement 
deserialization after studying known vulnerabilities.

Cheers,

Peter.

>
> On Sat, Oct 10, 2020 at 15:10 Peter Firmstone <pe...@zeus.net.au>
> wrote:
>
>> Some additional rationale:
>>
>> The original reason some people wanted a stable trunk branch was they
>> were concerned about the pace of development moving too fast, clearly
>> that's no longer a problem, now the stable development branch has become
>> an impediment as people on github can't see the development we are doing.
>>
>> Even Apache board members looked at github and thought we had no commits
>> for 3 years.
>>
>> We need people to see the ongoing work on River, so they have confidence
>> in the project's future and it's continued development and support.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 10/10/2020 9:03 AM, Peter Firmstone wrote:
>>> Currently the trunk branch is a stable branch, it is not for
>>> development code, let's make it so we can develop in trunk.  The vote
>>> concludes in two weeks.
>>>
>>> +1 Peter.
>>>
>>> Rationale:
>>>
>>> The project needs to migrate from SVN to GIT.
>>>
>>> The trunk branch is the GIT branch, currently it's only read only but
>>> we can make it a live writable git repository simply with an INFRA
>>> JIRA ticket.
>>>
>>> https://github.com/apache/river
>>>
>>> If we allow the trunk branch to become a development branch, then we
>>> can move the current modular develpment branch into trunk, and migrate
>>> other components not currently in the trunk branch like the ldj-tests,
>>> surrogate and other bits and pieces, which are also in a development
>>> state not ready for release.  Note that these should probably go under
>>> their own directory in trunk.
>>>
>>> Doing this will preserve the commit history of Apache River.
>>>
>>> Are there any git experts on the list?
>>>
>>> If this is not the right way to go about the migration to git, please
>>> give us your thoughts?
>>>
>>> Regards,
>>>
>>> Peter.
>>>