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 <peter.firmst...@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.
