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.
