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: <4D321F5D.4050701@zeus.net.au>
Date: Sun, 16 Jan 2011 08:27:41 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: build mechanisms
References: <4D2EDFE3.8000307@qcg.nl>
	<AANLkTikFvtWhwVRnNqdVX8W6xjv669orfQ0SPMd6pFfi@mail.gmail.com>
	<4D300E33.5080408@qcg.nl>	<4D301D42.5000601@zeus.net.au>
	<AANLkTimhECb3Xr7e1waqgC1tgahS54UvYKPDcstxYkhD@mail.gmail.com>
	<4D30255F.3070006@qcg.nl>
	<AANLkTin46sjP-=5TFqKd95sqH4zy_1K=kF-1U9fPgSJ+@mail.gmail.com>
	<4D302EAA.7020406@qcg.nl>
	<AANLkTik3NyJgefR=bLJaT9QbGfmf3pRvT6ZP975qTBzY@mail.gmail.com>
 <AANLkTimVaCZQMUvczqPV+osWJhh-6Kr0quHHyVDKEVyF@mail.gmail.com>
 <4D3037CB.6020007@qcg.nl> <4D303A81.3070508@zeus.net.au>
 <4D303FD2.1010108@qcg.nl>
In-Reply-To: <4D303FD2.1010108@qcg.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sim IJskes - QCG wrote:
> On 14-01-11 12:58, Peter Firmstone wrote:
>>> I'm all for development on the trunk. Stabilisation can take place in
>>> a branch.
>>>
>>
>> I believe I fell foul of that mistake not so long ago, I'd been
>> developing in trunk, only to discover that quite a number of tests
>> weren't run by qa.run, the changes had to be reverted and development
>> continued in skunk.
>>
>> After that I believe the consensus was to develop in skunk and then
>> bring / merge code into trunk.
>
> No, what we had was:
> - integration of the total QA
> - QA finding bugs
> - Reverts of some of your changes
> - QA finding less bugs, still not perfect due to QA.
>
> The missing step was here, reintegrating your changes, in a stepwise 
> manner, reviewing and checking if the total QA result stayed the same.
>
> correct?
>
Yes, that was our initial plan after discovering the test failures, 
however it seemed the consensus at the time was to experiment in skunk, 
then merge at a later date, although at the time we reverted all changes 
that weren't bug fixes.

I'm still working on these changes in skunk, one is a Service API called 
a StreamServiceRegistrar, for the internet, intended to allow a client 
to lookup an infinitely large set of results, but process them locally 
in small batches, represented by a stream.  Although to date there 
hasn't been a lot of interest in it.

The other is a new Dynamic Policy Provider, intended to support 
revocation, and combined with a result caching SecurityManager ( caches 
results for AccessControlContext's for extremely fast repeated security 
checks, these caches are cleared when revocation occurs) utilise Li 
Gong's method Guard pattern. Li Gong's Method Guard pattern ensures 
security sensitive objects are not passed by reference, which might lead 
to a security breach, by code that doesn't perform adequate security 
checking prior to allowing a reference to escape.  Instead these 
security sensitive objects have their conditions tested every method 
invocation. Security becomes part of the object, not some external 
concern.  Not all Permissions can be revoked, in cases where permissions 
are checked in a constructor or before returning a reference, these 
permissions are not revokeable since references to security sensitive 
objects are allowed to escape.  To work around this I've designed a 
DelegatePermission which is a Permission when granted, allows a delegate 
(proxy) object to perform the security sensitive operation, without 
allowing a reference to escape.  For example a SocketPermission is 
encapsulated in a DelegatePermission, which allows a delegate proxy to 
encapsulate a Socket and invoke methods, without allowing the Socket 
reference to escape.

By not allowing references to security sensitive objects to escape, we 
can have two separate Subjects utilise the same code, without concern 
one Subject might be able to obtain information, based on privileges the 
other Subject has.

Cheers,

Peter.