Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4CA9AE5B.7050208@qcg.nl>
Date: Mon, 04 Oct 2010 12:37:15 +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.11) Gecko/20100713 Thunderbird/3.0.6
MIME-Version: 1.0
To: river-dev@incubator.apache.org
CC: Michal Kleczek <michal.kleczek@xpro.biz>
Subject: Re: Towards Internet Jini Services (trust)
References: <4C9DB5BF.8090307@zeus.net.au>
 <AANLkTimS6dg85wXqPW99qBrU23sK=Y5qK6X7c9YOsWD-@mail.gmail.com>
 <CA36A28E7BFA4F80916058A3436B14CA@irt.vein.hu>
 <201010011500.49853.michal.kleczek@xpro.biz>
In-Reply-To: <201010011500.49853.michal.kleczek@xpro.biz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/01/2010 03:00 PM, Michal Kleczek wrote:
> 3. I agree with Tom that making sure the code comes from a known source is
> enough to make a decision whether to run this code or not. But Jini already
> checks that (well... almost)- the only hole is that the check is done _after_
> deserialization - so it means the code was executed _before_ the check was
> done. My question actually is - why don't we check an object before it is
> deserialized?

A possible solution might be, to enforce code download to use TLS and 
verify if the othersides ceritificate matches the downloaders trustlist. 
We can extends this by enforcing the downloaded jars/classes to be 
signed with a similar certificate.

A "once bitten measure" could be, if a server violates this rule, it 
will automatically be taken of the trustlist.

Gr. Sim