"once we publish them we're stuck with them" Why? Presumably we're stuck with them in the same way that Intel are stuck with continuing to support a huge legacy?
Of course I don't subscribe to such an attitude - if they're broken, we fix them. Even internet API's behave this way in spite of all the good REST'ian things said about preserving URL's etc because nothing else is practical. We routinely see fork'ing of internet API's or versioning where an old API remains but in a run-down, no longer supported state whilst development goes on elsewhere. That's the equivalent of leaving an API in an old version of the River kit and replacing it in a newer version. Nothing is perfect at release, there's nothing wrong with trying to be as right as possible but there are limits and we need to recognise that rather than obsess over achieving the impossible. Dan. On 11 January 2012 01:26, Peter Firmstone <j...@zeus.net.au> wrote: > Having a look at any new interfaces, once we publish them we're stuck with > them, so any thoughts or questions (Do I need to improved docs etc) would be > appreciated. > > Regards, > > Peter. > > > Tom Hobbs wrote: >> >> I can try and find some time for you. Let me know what you need and I'll >> do my best. >> >> Sent via mobile device, please forgive typos and spacing errors. >> >> On 10 Jan 2012 12:17, "Peter Firmstone" <j...@zeus.net.au> wrote: >> >> >>> >>> Tom & Dan, thanks for the support, we're probably looking at a dry run by >>> the weekend, right now I'm running the tests again, this run is expected >>> to >>> pass, I'm just checking for any regressions (same code in svn). I'll >>> clean >>> out all the redundant code, followed by some refactoring to move new >>> public >>> utility classes into package private where possible. >>> >>> I've you've got some time, I could use a hand to go over the new code to >>> tidy up any loose ends, make sure any new public api looks right before >>> we >>> merge, so we can release quickly, once the merge is complete. >>> >>> At this point, the code's only been tested on sparc. >>> >>> Cheers, >>> >>> Peter. >>> >>> Dan Creswell wrote: >>> >>> >>>> >>>> Agreed, remember --dry-run will give you a preview of what's to come >>>> in a merge if you have concerns... >>>> >>>> On 10 January 2012 10:08, Tom Hobbs <tvho...@googlemail.com> wrote: >>>> >>>> >>>> >>>>> >>>>> Let SVN do the merge, your changes might be extensive but I doubt there >>>>> has >>>>> been much movement in those files since you checked them out. So the >>>>> merge >>>>> will probably be more of a replace. >>>>> >>>>> I'm hoping to get some coding done in the next few weeks - at last! So >>>>> we >>>>> might have enough changes soon for a release. >>>>> >>>>> Keep up the good work, Peter. >>>>> >>>>> Sent via mobile device, please forgive typos and spacing errors. >>>>> >>>>> On 10 Jan 2012 06:20, "Peter" <j...@zeus.net.au> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> The new security manager and policies are almost ready to merge back >>>>>> into >>>>>> trunk. >>>>>> >>>>>> Any svn merge tips would be much appreciated. >>>>>> >>>>>> First, I'd like to move some policy implementation classes that are at >>>>>> present public in org.apache.river.*, into package private net.jini.* >>>>>> namespaces, to reduce the public api. >>>>>> >>>>>> Not all of the code will be included, classes, like >>>>>> ConcurrentPermissions >>>>>> (and all policy cache associated classes), even though far better than >>>>>> Permissions, will be discarded, as recent developments (eliminating >>>>>> policy >>>>>> cache) have made them redundant. >>>>>> >>>>>> DelegatePermission is still there, designed to work with delegate >>>>>> wrapper >>>>>> classes that encapsulate sockets and and file handles, to enable >>>>>> removal of >>>>>> temporarily granted permissions. >>>>>> >>>>>> Example: A downloaded proxy is granted a SocketPermission to contact >>>>>> its >>>>>> server, if during deserialisation, the proxy modifies some public >>>>>> static >>>>>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some >>>>>> platform >>>>>> classes with its own, it leaves some of its own proxy code on the >>>>>> stack >>>>>> context. The proxy after being downloaded is found to be untrusted >>>>>> and >>>>>> discarded. >>>>>> >>>>>> Every time the object the proxy has injected into the platform is >>>>>> accessed, it steals information and sends it back to its originating >>>>>> host. >>>>>> >>>>>> If a DelegatePermission(**SocketPermission p) is granted instead, the >>>>>> proxy >>>>>> recieves a socket that denies access when the permission is revoked, >>>>>> when >>>>>> trust can't be verified. >>>>>> >>>>>> The proxy could still perform a denial of service, by causing an out >>>>>> of >>>>>> memory error during deserialisation. >>>>>> >>>>>> DelegatePermission can also be used to grant temporary or limited >>>>>> access >>>>>> to Principals, eg after downloading 1GB, downloads are revoked and >>>>>> regranted at the next monthly cycle, something sililar could be used >>>>>> to >>>>>> limit writes to the file system. >>>>>> >>>>>> Obviously you'll need to buffer the input or output streams, to >>>>>> balance >>>>>> how often checks are performed, that is, if you choose to utilise it. >>>>>> >>>>>> A DelegateSocketFactory that can be used to encapsulate existing >>>>>> SocketFactory's will be released at a later date to enable >>>>>> DelegatePermission controlled streams and channels. Note any >>>>>> ProtectionDomains with SocketPermission will still have access to the >>>>>> same >>>>>> channel. >>>>>> >>>>>> DelegatePermission is intended to be a dynamically or runtime granted >>>>>> Permission. >>>>>> >>>>>> To function it requires a DelegateSecurityManager, each stack context >>>>>> domain must have permission either for the DelegatePermission or it's >>>>>> representative Permission. >>>>>> >>>>>> This was one motivation for a securitymanager cache, it needed to be >>>>>> as >>>>>> fast as possible and non blocking, unlike policy cache. >>>>>> >>>>>> Using delegates is of course optional. >>>>>> >>>>>> The other thing I was toying with was using deny as well as grant in >>>>>> policy files: >>>>>> >>>>>> Where denials would be checked first by the policy prior to checking >>>>>> grants: >>>>>> >>>>>> So you could deny a proxy access to the local network, whilst granting >>>>>> it >>>>>> access to the entire internet, with two simple policy statements. >>>>>> >>>>>> Or you could allow access to a directory, but deny access to a user >>>>>> policy >>>>>> file contained in that directory, for principal based grants. >>>>>> >>>>>> The syntax would be identical to a grant statement in policy files, >>>>>> except >>>>>> deny replaces grant. >>>>>> >>>>>> But then I realised despite the advantages, it adds complexity, >>>>>> because >>>>>> the deny statement could have unintended scope narrowing / widening >>>>>> consequences and Permissions like SocketPermission don't work as well >>>>>> as >>>>>> intended, it would be simpler to dynamically grant Permissions on an >>>>>> as >>>>>> needed basis. >>>>>> >>>>>> So any last remaining traces of deny must be removed. >>>>>> >>>>>> Instead of using deny in policy grants, I figure that proxy's can >>>>>> optionally include permissions.perms files under META-INF in their jar >>>>>> files as a hint to clients. By using the least priviledge model and >>>>>> limiting the GrantPermissions given to Principals administrators can >>>>>> limit >>>>>> Permissions users can grant to proxy's. >>>>>> >>>>>> The proxy developers would need to be aware they might not be granted >>>>>> all >>>>>> the permissions they'd like and offer reduced functionality by >>>>>> catching >>>>>> SecurityException. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Peter. >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> >> >> >> > >
