Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4CAF065E.4080400@qcg.nl>
Date: Fri, 08 Oct 2010 13:54:06 +0200
From: Sim IJskes - QCG <sim@qcg.nl>
Organization: Quality Consultancy Group b.v.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
References: <4C9DB5BF.8090307@zeus.net.au>
 <201010072157.48994.michal.kleczek@xpro.biz> <4CAEFA39.6010402@qcg.nl>
 <201010081309.13144.michal.kleczek@xpro.biz>
In-Reply-To: <201010081309.13144.michal.kleczek@xpro.biz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/08/2010 01:09 PM, Michal Kleczek wrote:
> On Friday 08 of October 2010 13:02:17 Sim IJskes - QCG wrote:
>> On 10/07/2010 09:57 PM, Michal Kleczek wrote:
>>> So...
>>> I've spent a day on some thinking and prototyping and hopefully I got an
>>> idea. Here is an outline:
>>
>>> 1. We annotate classes with an object implementing Module interface:
>> Is it safe to say that you are basically enhancing the codebase
>> annotation pattern?
> Basically - yes.
> Although I am not sure I understand precisely your question... :)

You understood correctly. :-) (i should have said, construct, well ok).

I noticed the readAnnotation of MarshallInputStream reads an Object and 
then casts it to a String. Are we sure that this is not a possible 
vector for a deserialization attack? Personally i would have taken a 
UTF-8 String (with limited length), but if you only unmarshall Objects 
from TLS connections, that you check first, i guess its ok.

So your solution is allowing for different credentials between the TLS 
and the code source, and checking these credentials.

Is this package pluggable onto river without modifications in river?

Gr. Sim