<div dir="ltr"><br><br><div class="gmail_quote">On Tue Dec 23 2014 at 1:35:14 PM Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21/12/14 06:36, Mic Bowman wrote:<br>
<br>
><br>
> 2) example serialization -- there is an example in the document.<br>
><br>
> {<br>
> "$type": "Dispatcher.Messages.<u></u>CreateCap<u></u>abilityRequest",<br>
><br>
> "_AsyncRequest": false,<br>
> "_Capability": "a1b108dc-11aa-44cb-a971-<u></u>760db<u></u>adef07c",<br>
> "_Domain": "Dispatcher",<br>
> "_Scene": "Test Region",<br>
> "DomainList": ["Dispatcher", "RemoteControl"],<br>
> "FirstName": "Test",<br>
> "LastName": "User",<br>
> "HashedPasswd": "<u></u>99cafb4ff0e3a8a6708f3854b713b<u></u>5<u></u>52",<br>
> "LifeSpan": 300,<br>
> "UserID": "16d0f788-2066-4b64-b248-<u></u>ffa23<u></u>9f62240"<br>
> }<br>
<br>
So, an issue here on any use over untrusted networks (i.e. the internet) may be continual sending of an MD5 password,<br>
which for any common password will not be hard to crack.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, default login over http is currently worse.<br>
<br></blockquote><div><br></div><div>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...<br></div><div><br></div><div>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? :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In both cases, it should really be necessary, quite possibly mandatory, to use https though that involves setting up the<br>
probably self-signed cert, etc. I think Teravus implemented that for login but I have never got round to digging up the<br>
details.<br>
<br>
><br>
> 3) a new communication<br>
><br>
> well... its never stopped us before. you forgot the stats interface, the remote administration interface, and the<br>
> websocket interface. oh... and don't forget all the methods that LSL supports. i'm sure there are more.<br>
<br>
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<br>
a hodge-podge of entirely different calling formats for different facilities where there is no technical reason for them<br>
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<br>
that this kind of approach should be used for future similar interfacing facilities, not something different every<br>
single time.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> 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<br>
> core. they are not built or compiled as part of building or installing opensim. its more like distributing a bunch of<br>
> assets for an avatar's library.<br>
><br>
> all that being said... if we actually had a reasonable distribution mechanism we wouldn't be having this conversation<br>
> because many (most) of the modules we package as optional modules should be loaded dynamically. something like PyIP or<br>
> CPAN. but we don't have one of those.<br>
><br>
> 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<br>
> digging for client libraries from some other site? while someone could generate their own json libraries, the effort of<br>
> putting it in core is really not worth it for the *very* small number of people who will do that. on the other hand...<br>
> if there are some useful commands already distributed with core (in a utility director or something), then we have added<br>
> value.<br>
<br>
I do appreciate your argument. As Tommy mentioned, there is NuGet but I'm not sure how mature it is for Mono or even<br>
stuff outside Visual Studio (which seems to be its main use).<br>
<br>
I would regard anything in the OpenSimulator tar.gz as part of core.<br>
<br>
To me, among the problems with bundling client libraries with OpenSimulator are<br>
<br>
1) Which languages? The last thing we need is a free-for-all.<br>
2) Where do you stop? OpenSimulator has a large surface. I could put in all my code for interfacing with services, for<br>
instance, where PHP made the most sense (ugh). Why not then extend to stats analysis code (written in Python)? Why not<br>
then a web interface?<br>
3) If someone wants to contribute then it has to be a core process and is very tied to OpenSimulator. I would argue<br>
this discourages reimplementation in other servers and raises the bar where this might not otherwise be necessary.<br>
Indeed, I have received a request to separate out pCampbot so ppl can work on it without being part of core. I don't<br>
think this is unreasonable in the long run though it's non-trivial to do (it relies on opensim console stuff) and it<br>
would have to be a decision agreed by core.<br>
<br>
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.<br>
<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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. </div><div><br></div><div>--mic</div><div><br></div><div><br></div><div><br></div></div></div>