[Opensim-dev] dispatcher interface

[Mic Bowman]

On Tue Dec 23 2014 at 1:35:14 PM Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> On 21/12/14 06:36, Mic Bowman wrote:
>
> >
> > 2) example serialization -- there is an example in the document.
> >
> >     {
> >          "$type": "Dispatcher.Messages.CreateCapabilityRequest",
> >
> >          "_AsyncRequest": false,
> >          "_Capability": "a1b108dc-11aa-44cb-a971-760dbadef07c",
> >          "_Domain": "Dispatcher",
> >          "_Scene": "Test Region",
> >          "DomainList": ["Dispatcher", "RemoteControl"],
> >          "FirstName": "Test",
> >          "LastName": "User",
> >          "HashedPasswd": "99cafb4ff0e3a8a6708f3854b713b552",
> >          "LifeSpan": 300,
> >          "UserID": "16d0f788-2066-4b64-b248-ffa239f62240"
> >     }
>
> So, an issue here on any use over untrusted networks (i.e. the internet)
> may be continual sending of an MD5 password,
> which for any common password will not be hard to crack.
>
That said, default login over http is currently worse.
>
>
You only send the password once on capability creation. After that,
messages have the capability sent, not the password (the password is a
parameter for this specific message type). Fixing the password replay
attack is not hard, but it does mean more fundamental changes to the
simulator (like creating a public/private key pair that could be used to
encrypt just the capability creation, or forcing calls over an SSL
connection). The pattern of creating a limited use capability has the
advantage of only needing one "really secure" exchange to create the
capability...

And... part of me says "you've got to be kidding". Given the number of
holes you can drive a truck through in opensim security? Seriously? :-)


> In both cases, it should really be necessary, quite possibly mandatory, to
> use https though that involves setting up the
> probably self-signed cert, etc.  I think Teravus implemented that for
> login but I have never got round to digging up the
> details.
>
> >
> > 3) a new communication
> >
> > well... its never stopped us before. you forgot the stats interface, the
> remote administration interface, and the
> > websocket interface. oh... and don't forget all the methods that LSL
> supports. i'm sure there are more.
>
> That's true, but I don't think that's an argument for continuing to do
> it.  Do you think it's reasonable to always have
> a hodge-podge of entirely different calling formats for different
> facilities where there is no technical reason for them
> to be different?  I'm not saying dispatcher has to be changed but if it
> isn't then I think we should have some agreement
> that this kind of approach should be used for future similar interfacing
> facilities, not something different every
> single time.
>

You know I agree with you. That being said... You also know that the bulk
of the communication mechanisms in OpenSim are essentially unique to a
particular (remote admin, LSL functions, stats, etc). They are not easily
generalized nor are they particularly well layered to allow for
generalization. Show me a mechanism in opensim that is well layered enough
to handle these messages with both binary & text encoding over both
streaming & packet protocols and i will gladly use it.


> >
> > 4 there would only be C# in core. the only non-C# code is the client
> libraries which may or may not be distributed with
> > core. they are not built or compiled as part of building or installing
> opensim. its more like distributing a bunch of
> > assets for an avatar's library.
> >
> > all that being said... if we actually had a reasonable distribution
> mechanism we wouldn't be having this conversation
> > because many (most) of the modules we package as optional modules should
> be loaded dynamically. something like PyIP or
> > CPAN. but we don't have one of those.
> >
> > so my question is... what's the point of putting it in core at all if we
> going to require anyone who uses it to go
> > digging for client libraries from some other site? while someone could
> generate their own json libraries, the effort of
> > putting it in core is really not worth it for the *very* small number of
> people who will do that. on the other hand...
> > if there are some useful commands already distributed with core (in a
> utility director or something), then we have added
> > value.
>
> I do appreciate your argument.  As Tommy mentioned, there is NuGet but I'm
> not sure how mature it is for Mono or even
> stuff outside Visual Studio (which seems to be its main use).
>
> I would regard anything in the OpenSimulator tar.gz as part of core.
>
> To me, among the problems with bundling client libraries with
> OpenSimulator are
>
> 1) Which languages?  The last thing we need is a free-for-all.
> 2) Where do you stop?  OpenSimulator has a large surface.  I could put in
> all my code for interfacing with services, for
> instance, where PHP made the most sense (ugh).  Why not then extend to
> stats analysis code (written in Python)?  Why not
> then a web interface?
> 3) If someone wants to contribute then it has to be a core process and is
> very tied to OpenSimulator.  I would argue
> this discourages reimplementation in other servers and raises the bar
> where this might not otherwise be necessary.
> Indeed, I have received a request to separate out pCampbot so ppl can work
> on it without being part of core.  I don't
> think this is unreasonable in the long run though it's non-trivial to do
> (it relies on opensim console stuff) and it
> would have to be a decision agreed by core.
>
> I'm not saying the kitchen sink approach is necessarily bad but I think
> either you do include a lot of stuff or very little/none.  I still prefer
> external repositories for client code, I don't think it's so bad and forces
> the documentation to be better.
>
>
So let me come back to this question... what's the purpose of putting this
in core? Its far more work for me and the only benefit i personally get out
of it is that if you change the name of a threading function, you'll know
you broke the dispatcher code right away so i don't have to go digging
around trying to figure out what's changed to fix it myself. (And you don't
make that kind of change very often so its not a big deal.) If people have
to go to a separate repository, then why wouldn't I just put a package
there that they can extract into their opensim directory that includes the
dll's, the config file & whatever client code/applications are necessary?

At this point I'm thinking that we should just skip core inclusion & i'll
just keep managing the dispatcher in a separate repository. Figuring out
how to make an easily installable opensim package (and package manager)
seems like a better use of the time in the long run.

--mic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20141223/9374011c/attachment-0001.html>