:) Agree re: users@
For a bit more context of where I'm coming from: "opinionated software" (http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php) We can potentially improve River's appeal by making some tough choices.... On 10 June 2011 16:53, Tom Hobbs <tvho...@googlemail.com> wrote: > At risk of aligning myself with the flamebait ;-), this isn't a bad idea. > We've got a number of major version number style changes in the pipeline. > Lets talk about the possibility of rolling this into that. > > Lets also make sure such discussions find their way onto users@ as well > though. > > Cheers Dan. > > On 10 Jun 2011 16:47, "Dan Creswell" <dan.cresw...@gmail.com> wrote: >> Controversial position: Why don't we just deprecate the entirety of V1? >> >> That means less work to do, no nasty dark corner workarounds as we try >> and retain compatibility, a clear policy on what will work with what >> etc. Fact is V2 has been around so long that most people are surely >> using it by now? >> >> I just am not a fan of backward compatibility without some very good >> reasons, history shows this sort of "holding onto the past" to be a >> nightmare for all concerned. One needs to look no further than the JDK >> itself which is full of cruft and cut corners for the sake of >> compatibility. >> >> On 10 June 2011 08:51, Peter Firmstone <j...@zeus.net.au> wrote: >>> _Unicast Discovery v2 - Unmarshalling Attack with Registrar proxy._ >>> >>> During unicast discovery, we have the option of using SSL, Kerberos or > x500 >>> discovery implementations, unfortunately, if the unicast discovery >>> implementation being used doesn't comply with constraints for > Authentication >>> and Confidentiality, the constraints are re tried against the > unmarshalled >>> registrar proxy, bypassing the security benefits these implementations >>> provide. >>> >>> I believe this was an oversight to allow codebase integrity constraints > to >>> bubble up as Unfulfilled Constraints to the upper layer, where they're >>> checked against the unmarshalled proxy, unfortunately it appears to be a >>> mistake to allow Authentication and Confidentiality constraints to bubble > up >>> during discovery. >>> >>> I think we should change this specifically for Authentication and >>> Confidentiality constraints, if these are requested but not satisfied > during >>> discovery we should throw an UnsupportedConstraintException. >>> >>> Doing so avoids the DOS unmarshalling attack which is possible during >>> unmarshalling of an unauthenticated registrar proxy. >>> >>> _Unicast Discovery v1_ >>> >>> In light of Unicast Discovery v1's total lack of support for security, I >>> believe we should deprecate it, for this to happen we also need to > provide a >>> way for existing deployments to migrate. >>> >>> LookupLocator performs unicast discovery v1. ConstrainableLookupLocator >>> extends LookupLocator and is used for v2 unicast discovery constraints. >>> >>> >>> _But what about Multicast Discovery? >>> >>> _Multicast discovery produces a LookupLocator which is used by Unicast >>> Discovery to retrieve a registrar proxy. >>> >>> _Multicast Request Protocol v1 >>> >>> _Please add any security concerns here. >>> >>> No integrity support - how much of a problem is this? >>> >>> _Multicast Request Protocol v2 >>> >>> _x500 integrity supported_ >>> >>> __Multicast Announcement Protocol v1 >>> >>> _Please add any security concerns here. >>> >>> No integrity support, packets can be modified in transit, but this > doesn't >>> seem to be much of a concern for announcement anyway. >>> _ >>> __Multicast Announcement Protocol v2 >>> >>> _x500 integrity supported. >>> >>> Note that Multicast v2 supports x500 integrity constraints, in addition > to >>> plain text, while it doesn't prevent someone viewing the contents of the >>> packet, it ensures the packets contents haven't been tampered with. >>> >>> I don't see a reason to deprecate Multicast Discovery v1 for existing >>> deployments, x500 integrity is an obvious advantage, but the real threat > to >>> security occurs during Unicast Discovery, when unmarshalling attacks can >>> occur. >>> >>> So we could, in theory at least, use a LookupLocator from Multicast v1 >>> discovery with Unicast v2 discovery in newly deployed clients and >>> registrars to remain network compatible with existing clients that only >>> support D v1. >>> >>> Figuring out how to solve the migration problem? >>> >>> I think most of the migration problem exists with Multicast, so for > legacy >>> support reasons a djinn could employ Multicast v1 with a combination of >>> Unicast v1 (for older clients) and v2 for the latter. >>> >>> Registrar's could have providers for both v1 and v2 discovery and thus > reply >>> to both. >>> >>> This will require some revisions to discovery utilities (implementing >>> DiscoveryGroupManagement) for our next release, in order to provide an >>> upgrade path for existing djinn's. >>> >>> Any ideas? >>> >>> Cheers, >>> >>> Peter. >>> * >>> *_ >>> _ >>> >>> >>> >>> >>> Hi Peter. >>> >>> I don't remember enough about this to know for sure if this problem is as >>> stated. I thought the resources were defined in the default Jini 2.0 JAR >>> files, but that could have changed after my time. Mike Warres was the >>> initial author of this stuff, but others at Sun took over from him before >>> the effort stopped. I don't know if any of those guys are still following >>> the conversation. >>> >>> - Tim >>> >>> On Dec 12, 2010, at 2:31 PM, Peter Firmstone <j...@zeus.net.au> wrote: >>> >>>> Tim, >>>> >>>> Do you know of an alternative plan to Chris' suggestion, for migration >>>> from Discovery V1 to V2? >>>> >>>> It probably all happened too long ago to remember now, just wondering if >>>> anything comes to mind? >>>> >>>> I'll look into it further too. >>>> >>>> Cheers, >>>> >>>> Peter. >>>>> Since its inception, my project has been using DiscoveryV1 and we've >>>>> never dealt with Jini constraints. Peter's comments last week about > the >>>>> flexibility of DiscoveryV2 inspired me to learn more about it and to >>>>> experiment a bit. To my surprised, I found it very difficult to figure >>>>> out how to turn V2 on (I ended up reading a lot of source code), and it >>>>> looks like it's nearly impossible to migrate in a backward compatible >>>>> way, i.e. continuing to fully interact with services that were deployed >>>>> with the default preference for V1. I would LOVE to be told that I've >>>>> made a mistake or missed something important... >>>>> >>>>> * To switch Reggie to use V2 for multicast announcements: >>>>> >>>>> com.sun.jini.reggie { >>>>> discoveryConstraints = new BasicMethodConstraints(new >>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO)); >>>>> } >>>>> >>>>> * To switch group discovery to use V2 for multicast requests: >>>>> >>>>> net.jini.discovery.LookupDiscovery { >>>>> discoveryConstraints = new BasicMethodConstraints(new >>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO)); >>>>> } >>>>> >>>>> * To create a locator that uses V2 for directed unicast discovery: >>>>> >>>>> new ConstrainableLookupLocator(host, port, new >>>>> BasicMethodConstraints(new InvocationConstraints(null, >>>>> DiscoveryProtocolVersion.TWO))); >>>>> >>>>> >>>>> * To tell DiscoveryV2 how to encode and decode the messages, create a >>>>> file called >>>>> "META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider" and >>>>> put in lines (for example): >>>>> >>>>> com.sun.jini.discovery.plaintext.Client >>>>> com.sun.jini.discovery.plaintext.Server >>>>> >>>>> However (and this is the key problem), any deployed clients or Reggies >>>>> which lack the >>>>> META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file >>>>> will not be able to decode the incoming messages and will drop them > with >>>>> an error message about unknown format IDs. >>>>> >>>>> So, the only solution I can see is to start shipping new services with >>>>> the DiscoveryFormatProvider file in place, and then wait several >>>>> releases until all of my old deployments have been retired, and then >>>>> turn on the V2 preference. Am I wrong? Is there a trick to get >>>>> already-deployed clients to use a format ID that they don't know about? >>>>> Surely other people have had similar problems deploying brand-new >>>>> DiscoveryFormatProvider implementations? >>>>> >>>>> Is there a way to make services send out both V1 and V2 multicasts? Is >>>>> there a way to tell LookupDiscovery.UnicastDiscoveryTask to try V2 > first >>>>> and then retry with V1? >>>>> >>>>> I feel like I'm missing some central point... >>>>> >>>>> Chris >>> >>> >>> >
