river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: deserialization remote invocation strategy
Date Wed, 15 Feb 2017 12:22:38 GMT

Will see what I can do over the weekend.

For users already familiar with River, there's not much new as it's mostly abstracted behind
ServiceDiscoveryManager, LookupCache' ProxyPreparer and ServiceItemFilter.

The non trivial part is implementing AtomicSerial.

An introduction to AtomicSerial is available on the jgdms wiki.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Michał Kłeczek <michal@kleczek.org>
Sent: 15/02/2017 09:07:33 pm
To: dev@river.apache.org
Subject: Re: deserialization remote invocation strategy

Reviewing just the source code without any high level overview and  
explanation how and why it is implemented in a particular way 
is difficult (if possible at all). 

That is why it would be really helpful if the questions asked were answered.

Not only researchers are interested - also potential users and contributors. 


Peter wrote: 
> I can't make any guarantee that it is secure, but the more people review it, the more likelihood bugs and flaws will be identified.

> I'm especially interested in security researchers checking it out if they're interested.

> Cheers, 
> Peter. 
> Sent from my Samsung device. 
>    Include original message 
> ---- Original message ---- 
> From: Michał Kłeczek<michal@kleczek.org> 
> Sent: 15/02/2017 08:04:39 pm 
> To: dev@river.apache.org 
> Subject: Re: deserialization remote invocation strategy 
>>   The code actually does what I've described above, but don't take my word for it, check it for youself. :)

>>   If you disagree, don't use it. 
> It works the other way around - before I decide to use it - I have to 

> understand how it works. 
> Even more so if we are talking about security. 
> That is why I consider scrutiny and questioning a Good Thing in this  
> context. 
> "Check for yourself" is not an encouraging advice in the area of security :)

> Cheers, 
> Michal 

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