You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <pe...@zeus.net.au> on 2016/02/25 12:52:55 UTC
The future thing
While we're waiting for people to review River 3.0's Release artifacts...
I've posted some of my more contraversial work on River security and ipv6 global discovery (internet announcement protocol) on github. The river community is free to cherry pick the code if it wants. I would have much preferred to have developed it collaboratively, there's room for improvement.
Features:
Updated support for tlsv1.2, removal of insecure cyphers, downgrading of all strong encryption cyphers and key exchanges circa 2005 to weak. New strong cyphers that are strong now Removal of non ephemeral DH key exchanges that are vulnerable to mim attacks.
Input validation for deserialization, DeserializationPermission.
New default method for ServiceRegistrar to help clients establish service trust prior to proxy codebase downloading.
Ability to make dynamic CodeSource and Certificate grants, after proxy authentication. You currently can’t make ClassLoader based grants to a proxy before its downloaded, to grant it DownloadPermission and DeSerializationPermission.
You can anonymously sign your jar files, provided you have a trusted X509 public cert for your service. This allows you to use the free Letsencrypt.org service, without requiring expensive codesigner certs.
Reduced network loads on Reggie and clients.
Delayed proxy unmarshalling, much faster. (thanks Gregg, don't understand why it wasn't adopted).
Delayed attribute unmarshalling, or don't download them at all if you don't need them.
Bootstrap proxy's all have the same limited local interfaces, limiting dynamic proxy class generation during lookup.
Ipv6 global and site local discovery.
My goal this year is to make available a public Jini / River like lookup service over ipv6.
I think this should be a useful experiment. The network protocols weren't ready for Jini in 1999. With ipv6, Jini / River (should it choose to) will no longer be restricted to private networks. Clients from one private subnet will be able to access services from another private subnet directly p2p.
A social network where users control their own data? Video links, messaging, file sharing? Dynamic discovery?
You know, thinking about it, a lossless image (bytes) could be used to discover your friends. That is, use an image attribute, text this image to your friends, then they can discover you using your image attribute.
Just a thought.
Cheers,
Peter.
Sent from my Samsung device.
Re: The future thing
Posted by Greg Trasuk <tr...@stratuscom.com>.
I think it’s difficult to talk about future features without context. So it would be helpful if we could express in a great level of detail what exactly we see people doing with River. Perhaps even build a proof-of-concept demonstration and use that to drive any changes to River.
Cheers,
Greg Trasuk
> On Feb 25, 2016, at 9:33 AM, Patricia Shanahan <pa...@acm.org> wrote:
>
> Thanks for getting this started.
>
> I think you have a high level vision of where you see River going in the future. It might be useful to state it here. The costs and benefits of changes are best evaluated in that sort of context.
>
> On 2/25/2016 3:52 AM, Peter Firmstone wrote:
>> While we're waiting for people to review River 3.0's Release
>> artifacts...
>>
>> I've posted some of my more contraversial work on River security and
>> ipv6 global discovery (internet announcement protocol) on github.
>> The river community is free to cherry pick the code if it wants. I
>> would have much preferred to have developed it collaboratively,
>> there's room for improvement.
>>
>> Features:
> ...
Re: The future thing
Posted by Patricia Shanahan <pa...@acm.org>.
Thanks for getting this started.
I think you have a high level vision of where you see River going in the
future. It might be useful to state it here. The costs and benefits of
changes are best evaluated in that sort of context.
On 2/25/2016 3:52 AM, Peter Firmstone wrote:
> While we're waiting for people to review River 3.0's Release
> artifacts...
>
> I've posted some of my more contraversial work on River security and
> ipv6 global discovery (internet announcement protocol) on github.
> The river community is free to cherry pick the code if it wants. I
> would have much preferred to have developed it collaboratively,
> there's room for improvement.
>
> Features:
...
Re: The future thing
Posted by Bryan Thompson <br...@systap.com>.
Peter,
This all sounds very interesting to me. I would also encourage the
development of IoT examples along the way to help capture enthusiasm in a
broader community.
I think that this will all be much easier if we can break down river into
multiple projects and move to a git-based process.
Can river (as a community) work on these things in parallel? New
directions and a more nimble code base and process?
Thanks,
Bryan
----
Bryan Thompson
Chief Scientist & Founder
Blazegraph
e: bryan@blazegraph.com
w: http://blazegraph.com
Blazegraph products help to solve the Graph Cache Thrash to achieve large
scale processing for graph and predictive analytics. Blazegraph is the
creator of the industry’s first GPU-accelerated high-performance database
for large graphs, has been named as one of the “10 Companies and
Technologies to Watch in 2016” <http://insideanalysis.com/2016/01/20535/>.
Blazegraph Database <https://www.blazegraph.com/> is our ultra-high
performance graph database that supports both RDF/SPARQL and
Tinkerpop/Blueprints APIs. Blazegraph GPU
<https://www.blazegraph.com/product/gpu-accelerated/> andBlazegraph DAS
<https://www.blazegraph.com/product/gpu-accelerated/>L are disruptive new
technologies that use GPUs to enable extreme scaling that is thousands of
times faster and 40 times more affordable than CPU-based solutions.
CONFIDENTIALITY NOTICE: This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP, LLC DBA Blazegraph. Any unauthorized review, use,
disclosure, dissemination or copying of this email or its contents or
attachments is prohibited. If you have received this communication in
error, please notify the sender by reply email and permanently delete all
copies of the email and its contents and attachments.
On Thu, Feb 25, 2016 at 6:52 AM, Peter Firmstone <
peter.firmstone@zeus.net.au> wrote:
> While we're waiting for people to review River 3.0's Release artifacts...
>
> I've posted some of my more contraversial work on River security and ipv6
> global discovery (internet announcement protocol) on github. The river
> community is free to cherry pick the code if it wants. I would have much
> preferred to have developed it collaboratively, there's room for
> improvement.
>
> Features:
>
> Updated support for tlsv1.2, removal of insecure cyphers, downgrading of
> all strong encryption cyphers and key exchanges circa 2005 to weak. New
> strong cyphers that are strong now Removal of non ephemeral DH key
> exchanges that are vulnerable to mim attacks.
>
> Input validation for deserialization, DeserializationPermission.
>
> New default method for ServiceRegistrar to help clients establish service
> trust prior to proxy codebase downloading.
>
> Ability to make dynamic CodeSource and Certificate grants, after proxy
> authentication. You currently can’t make ClassLoader based grants to a
> proxy before its downloaded, to grant it DownloadPermission and
> DeSerializationPermission.
>
> You can anonymously sign your jar files, provided you have a trusted X509
> public cert for your service. This allows you to use the free
> Letsencrypt.org service, without requiring expensive codesigner certs.
>
> Reduced network loads on Reggie and clients.
>
> Delayed proxy unmarshalling, much faster. (thanks Gregg, don't understand
> why it wasn't adopted).
>
> Delayed attribute unmarshalling, or don't download them at all if you
> don't need them.
>
> Bootstrap proxy's all have the same limited local interfaces, limiting
> dynamic proxy class generation during lookup.
>
> Ipv6 global and site local discovery.
>
> My goal this year is to make available a public Jini / River like lookup
> service over ipv6.
>
> I think this should be a useful experiment. The network protocols weren't
> ready for Jini in 1999. With ipv6, Jini / River (should it choose to) will
> no longer be restricted to private networks. Clients from one private
> subnet will be able to access services from another private subnet directly
> p2p.
>
> A social network where users control their own data? Video links,
> messaging, file sharing? Dynamic discovery?
>
> You know, thinking about it, a lossless image (bytes) could be used to
> discover your friends. That is, use an image attribute, text this image to
> your friends, then they can discover you using your image attribute.
>
> Just a thought.
>
> Cheers,
>
> Peter.
>
> Sent from my Samsung device.
>
>