[Opensim-dev] Security: multiple or the most generic?
Melanie
melanie at t-data.com
Tue Apr 14 12:27:21 UTC 2009
It seems you're forgetting the valid use case of multi-server sites.
Ultimate trust within a domain (today's "Grid") is a valid use case.
Melanie
DZO wrote:
> It may seem that by supporting as many of these as possible its making the
> task easier for the client, but I believe making a very generic version of
> option C, allowing each region to be customised to require varying levels of
> protection and pushing back the ease off use issue to the client would make
> the task simpler for opensim AND give the client the freedom to choose.
>
> For example you can attach multiple logins to an im messenger application or
> an email client, and use all of them seemlessly from one computer, so the
> viewers should be able to store grid / region passwords and manage them,
> allowing for strict password protection even on a region basis yet seemless
> useage / teleporting / walking for the client.
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
> opensim-dev-request at lists.berlios.de
> Sent: 14 April 2009 00:20
> To: opensim-dev at lists.berlios.de
> Subject: Opensim-dev Digest, Vol 20, Issue 35
>
> Send Opensim-dev mailing list submissions to
> opensim-dev at lists.berlios.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
> opensim-dev-request at lists.berlios.de
>
> You can reach the person managing the list at
> opensim-dev-owner at lists.berlios.de
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
> 1. Security: multiple or the most generic? (Diva Canto)
> 2. Re: Security: multiple or the most generic? (Diva Canto)
> 3. Re: Security: multiple or the most generic? (Ideia Boa)
> 4. Re: Security: multiple or the most generic? (Melvin Carvalho)
> 5. Re: Security: multiple or the most generic? (Melanie)
> 6. Re: Security: multiple or the most generic? (Diva Canto)
> 7. Re: Security: multiple or the most generic? (Stefan Andersson)
> 8. Re: Proposal: Drop VS 2005 suppost [Was: C# 3.0 vs .Net 2]
> (Stefan Andersson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 13 Apr 2009 10:37:15 -0700
> From: Diva Canto <diva at metaverseink.com>
> Subject: [Opensim-dev] Security: multiple or the most generic?
> To: opensim-dev at lists.berlios.de
> Message-ID: <49E3784B.1090001 at metaverseink.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I've been debating with myself and with some ppl in IRC about whether
> OpenSim should support many security schemes or shoot for the most generic
> one. Advice appreciated. Here's the situation.
>
> There are already 3 different authentication schemes on the pipeline for
> Teleports, one of them being the current one, and two being on my local
> non-committed changes. These 3 schemes are: (a) no authentication; (b)
> session authentication; and (c) key authentication (keys being unique,
> one-time strings for each client-server pair).
>
> (a) is what is currently in place -- hence my nagging about the lack of
> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
> (b) is a weak form of authentication that prevents spoofing from the outside
> of a grid, but that doesn't prevent spoofing from inside. That is, regions
> can find out the sessionID of users when they're logged in, and impersonate
> them. In open grids this is highly unsafe; but in walled-garden grids, this
> is perfectly fine.
> (c) is the strongest form, as it allows clients to have a lot more control
> -- not the raw Linden client, which doesn't quite do that, but others. (c)
> can also be implemented in the current setup, with the raw Linden client,
> and with server-side teleports. It's kind of meaningless in this case, but
> it's no worse than (b) for open grids.
>
> So, back to the original question. Should OpenSim support all of these and
> more, or should we shoot for (c) only?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 13 Apr 2009 10:43:40 -0700
> From: Diva Canto <diva at metaverseink.com>
> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
> To: opensim-dev at lists.berlios.de
> Message-ID: <49E379CC.1020508 at metaverseink.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The corollary being that multiple implies some clever software
> architecting...
>
> Diva Canto wrote:
>> I've been debating with myself and with some ppl in IRC about whether
>> OpenSim should support many security schemes or shoot for the most
>> generic one. Advice appreciated. Here's the situation.
>>
>> There are already 3 different authentication schemes on the pipeline for
>> Teleports, one of them being the current one, and two being on my local
>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>> session authentication; and (c) key authentication (keys being unique,
>> one-time strings for each client-server pair).
>>
>> (a) is what is currently in place -- hence my nagging about the lack of
>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>> (b) is a weak form of authentication that prevents spoofing from the
>> outside of a grid, but that doesn't prevent spoofing from inside. That
>> is, regions can find out the sessionID of users when they're logged in,
>> and impersonate them. In open grids this is highly unsafe; but in
>> walled-garden grids, this is perfectly fine.
>> (c) is the strongest form, as it allows clients to have a lot more
>> control -- not the raw Linden client, which doesn't quite do that, but
>> others. (c) can also be implemented in the current setup, with the raw
>> Linden client, and with server-side teleports. It's kind of meaningless
>> in this case, but it's no worse than (b) for open grids.
>>
>> So, back to the original question. Should OpenSim support all of these
>> and more, or should we shoot for (c) only?
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 13 Apr 2009 19:55:09 +0200
> From: Ideia Boa <ideiaboa at gmail.com>
> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
> To: diva at metaverseink.com, opensim-dev at lists.berlios.de
> Message-ID: <49E37C7D.5050109 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Yes and (c)
>
> Ideia Boa
>
> cumprimentos e boa pascoa Cristina
>
> Diva Canto wrote:
>> I've been debating with myself and with some ppl in IRC about whether
>> OpenSim should support many security schemes or shoot for the most
>> generic one. Advice appreciated. Here's the situation.
>>
>> There are already 3 different authentication schemes on the pipeline for
>> Teleports, one of them being the current one, and two being on my local
>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>> session authentication; and (c) key authentication (keys being unique,
>> one-time strings for each client-server pair).
>>
>> (a) is what is currently in place -- hence my nagging about the lack of
>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>> (b) is a weak form of authentication that prevents spoofing from the
>> outside of a grid, but that doesn't prevent spoofing from inside. That
>> is, regions can find out the sessionID of users when they're logged in,
>> and impersonate them. In open grids this is highly unsafe; but in
>> walled-garden grids, this is perfectly fine.
>> (c) is the strongest form, as it allows clients to have a lot more
>> control -- not the raw Linden client, which doesn't quite do that, but
>> others. (c) can also be implemented in the current setup, with the raw
>> Linden client, and with server-side teleports. It's kind of meaningless
>> in this case, but it's no worse than (b) for open grids.
>>
>> So, back to the original question. Should OpenSim support all of these
>> and more, or should we shoot for (c) only?
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: ideiaboa.vcf
> Type: text/x-vcard
> Size: 283 bytes
> Desc: not available
> Url :
> https://lists.berlios.de/pipermail/opensim-dev/attachments/20090413/96150b92
> /attachment-0001.bin
>
> ------------------------------
>
> Message: 4
> Date: Mon, 13 Apr 2009 20:06:07 +0200
> From: Melvin Carvalho <melvincarvalho at gmail.com>
> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
> To: diva at metaverseink.com, opensim-dev at lists.berlios.de
> Message-ID:
> <9178f78c0904131106h6f193ac6p7ba130f5b44c3f52 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Apr 13, 2009 at 7:37 PM, Diva Canto <diva at metaverseink.com> wrote:
>> I've been debating with myself and with some ppl in IRC about whether
>> OpenSim should support many security schemes or shoot for the most
>> generic one. Advice appreciated. Here's the situation.
>>
>> There are already 3 different authentication schemes on the pipeline for
>> Teleports, one of them being the current one, and two being on my local
>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>> session authentication; and (c) key authentication (keys being unique,
>> one-time strings for each client-server pair).
>>
>> (a) is what is currently in place -- hence my nagging about the lack of
>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>> (b) is a weak form of authentication that prevents spoofing from the
>> outside of a grid, but that doesn't prevent spoofing from inside. That
>> is, regions can find out the sessionID of users when they're logged in,
>> and impersonate them. In open grids this is highly unsafe; but in
>> walled-garden grids, this is perfectly fine.
>> (c) is the strongest form, as it allows clients to have a lot more
>> control -- not the raw Linden client, which doesn't quite do that, but
>> others. (c) can also be implemented in the current setup, with the raw
>> Linden client, and with server-side teleports. It's kind of meaningless
>> in this case, but it's no worse than (b) for open grids.
>>
>> So, back to the original question. Should OpenSim support all of these
>> and more, or should we shoot for (c) only?
>
> (c) is the most important; there is a very well established pattern
> using SSL, there should also be many libraries for this
>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 13 Apr 2009 20:16:30 +0200
> From: Melanie <melanie at t-data.com>
> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
> To: diva at metaverseink.com, opensim-dev at lists.berlios.de
> Message-ID: <49E3817E.5050005 at t-data.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Well, if a key is an arbitrary string, then it may also be a
> constant UUID value, e.g. the standard session id we have now, so
> (c) really includes (b).
>
> Now, my vision of the future 3d internet is that all grids will be
> walled gardens, trust domains, as an analog to a large, multi-server
> website. I see people move between those trust domains using the
> Hypergrid protocol and client side teleporting. I see people use
> nonlocal messaging (Jabber, etc) instead of local grid comms.
>
> Therefore, I believe the ability to run a trust domain with
> hypergrid ability should be maintained, we should not mandate that
> all protocols in all cases must assume untrusted regions, because I
> see those in the hypergrid, rather than the local grid in the future.
>
> Hypergridding between these trust domains, I believe, must involve
> the target domain's user server, which would, in the case of (c),
> negotiate the key with the viewer.
>
> So, for now, (c) is the way to go, just don't forget the (b) use
> case. Interregion trust should remain possible.
>
> Melanie
>
>
> Diva Canto wrote:
>> I've been debating with myself and with some ppl in IRC about whether
>> OpenSim should support many security schemes or shoot for the most
>> generic one. Advice appreciated. Here's the situation.
>>
>> There are already 3 different authentication schemes on the pipeline for
>> Teleports, one of them being the current one, and two being on my local
>> non-committed changes. These 3 schemes are: (a) no authentication; (b)
>> session authentication; and (c) key authentication (keys being unique,
>> one-time strings for each client-server pair).
>>
>> (a) is what is currently in place -- hence my nagging about the lack of
>> security in non-VPN'ed grids. But for VPN'ed grids this is perfectly fine.
>> (b) is a weak form of authentication that prevents spoofing from the
>> outside of a grid, but that doesn't prevent spoofing from inside. That
>> is, regions can find out the sessionID of users when they're logged in,
>> and impersonate them. In open grids this is highly unsafe; but in
>> walled-garden grids, this is perfectly fine.
>> (c) is the strongest form, as it allows clients to have a lot more
>> control -- not the raw Linden client, which doesn't quite do that, but
>> others. (c) can also be implemented in the current setup, with the raw
>> Linden client, and with server-side teleports. It's kind of meaningless
>> in this case, but it's no worse than (b) for open grids.
>>
>> So, back to the original question. Should OpenSim support all of these
>> and more, or should we shoot for (c) only?
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 13 Apr 2009 11:25:06 -0700
> From: Diva Canto <diva at metaverseink.com>
> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
> To: Melanie <melanie at t-data.com>
> Cc: opensim-dev at lists.berlios.de
> Message-ID: <49E38382.8050309 at metaverseink.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Melanie wrote:
>> Well, if a key is an arbitrary string, then it may also be a constant
>> UUID value, e.g. the standard session id we have now, so (c) really
>> includes (b).
> They are very different. A key is specific for one client-server pair.
> So for each region the client visits there is a unique key that the
> other regions might not know about. When TPs are performed on the
> server-side, this is equivalent to (b) because the regions are acting on
> behalf of the agent. But for client-side Teleports, this makes all the
> difference -- the regions don't know about the other regions' keys.
>
>> [...]
>> So, for now, (c) is the way to go, just don't forget the (b) use case.
>> Interregion trust should remain possible.
> Right. Even though my main focus is the Hypergrid, I'm a little
> reluctant in letting go of (b), and even of (a). The problem I'm
> debating is how to architect OpenSim so that these different schemes can
> co-exist without the code and configuration being a mess.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 13 Apr 2009 21:56:39 +0200
> From: Stefan Andersson <stefan at tribalmedia.se>
> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
> To: <diva at metaverseink.com>, <melanie at t-data.com>
> Cc: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
> Message-ID: <BLU134-W413FB4426FB3BE843EC1B7D57F0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> If we're going to do it 'right' from the start, then obviously, (c) as the
> general case and (b) as the special case should be the way to go.
>
>
>
> (Easy for me to say)
>
>
>
> And on a tangent, I'm closing in on having the AssetServer demanding a
> connection to a user server to resolve user urls. Thoughts?
>
>
>
> (It baffles me we don't seem to have that already - I'm not working on the
> AssetInventory server as I feel its ultimate destiny is still somewhat
> hazy?)
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
>> Date: Mon, 13 Apr 2009 11:25:06 -0700
>> From: diva at metaverseink.com
>> To: melanie at t-data.com
>> CC: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
>>
>> Melanie wrote:
>> > Well, if a key is an arbitrary string, then it may also be a constant
>> > UUID value, e.g. the standard session id we have now, so (c) really
>> > includes (b).
>> They are very different. A key is specific for one client-server pair.
>> So for each region the client visits there is a unique key that the
>> other regions might not know about. When TPs are performed on the
>> server-side, this is equivalent to (b) because the regions are acting on
>> behalf of the agent. But for client-side Teleports, this makes all the
>> difference -- the regions don't know about the other regions' keys.
>>
>> > [...]
>> > So, for now, (c) is the way to go, just don't forget the (b) use case.
>> > Interregion trust should remain possible.
>> Right. Even though my main focus is the Hypergrid, I'm a little
>> reluctant in letting go of (b), and even of (a). The problem I'm
>> debating is how to architect OpenSim so that these different schemes can
>> co-exist without the code and configuration being a mess.
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://lists.berlios.de/pipermail/opensim-dev/attachments/20090413/9e21b6e8
> /attachment-0001.html
>
> ------------------------------
>
> Message: 8
> Date: Mon, 13 Apr 2009 23:19:33 +0200
> From: Stefan Andersson <stefan at tribalmedia.se>
> Subject: Re: [Opensim-dev] Proposal: Drop VS 2005 suppost [Was: C# 3.0
> vs .Net 2]
> To: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
> Message-ID: <BLU134-W53C0DED1C30553BCD25C6AD57F0 at phx.gbl>
> Content-Type: text/plain; charset="windows-1252"
>
>
> I have now updated the wiki with the proposal, linking to
>
>
>
> http://opensimulator.org/wiki/Visual_Studio_2005
>
>
>
> from the main page. Please read article and add to it.
>
>
>
> On the page I have stated that 0.6.5 be the last version building on VS
> 2005. Ideally, I'd like to tag that now, and then introduce a VS 2005
> 'breaker' to really get things going.
>
>
>
> Do we have a 0.6.5-rc1 rev?
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
>
>
> From: stefan at tribalmedia.se
> To: opensim-dev at lists.berlios.de
> Date: Thu, 26 Mar 2009 12:32:04 +0100
> Subject: [Opensim-dev] Proposal: Drop VS 2005 suppost [Was: C# 3.0 vs .Net
> 2]
>
>
>
> I propose that
>
> "if nobody actually objects on this or the users list before 1st of May
> 2009, we'll drop VS 2005 support and move on".
>
> If I get no strong objections on this, I'll re-post a proposal and update
> the wiki with the proposal and guidelines to objecting, on friday 3rd of
> April 2009.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
>
>
> Date: Thu, 26 Mar 2009 10:47:21 +0000
> From: Chris at codetorque.co.uk
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>
>
>
>
>
> You may find some issues with that since it?s a CTP (pre-beta) from 2006, so
> some supported syntax in there may have changed for final release, but can?t
> say for certain.
>
> Teravus is correct in that VS2008 is available for free
> (http://www.microsoft.com/express/vcsharp/). Installing C# 2008 Express you
> also get SQL Server 2008 Express installed, so you have some options for
> using that out of the box too. C# Express should be able to handle most
> basic development tasks ? I guess it just depends on how nice you want to be
> to 2005 Pro or higher owners going forward as to whether to stay in 2.0 land
> or move on.
>
>
>
>
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Stefan Andersson
> Sent: 26 March 2009 07:45
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>
> Could anybody actually using VS 2005 comment on whether installing the Orcas
> CTP would solve this?
>
> http://www.microsoft.com/downloads/details.aspx?FamilyId=1E902C21-340C-4D13-
> 9F04-70EB5E3DCEEA&displaylang=en
>
> This is the community preview of the C# 3 extensions, made available as an
> extension to VS 2005.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
>> Date: Thu, 26 Mar 2009 01:27:42 -0400
>> From: teravus at gmail.com
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>>
>> Our issue here isn't mono support :) Mono has 3.0 support since
>> 1.9.1. It's our support of Visual Studio 2005 as a build tool.
>>
>> Visual Studio 2005 is the tool that doesn't understand code in C# 3.0 :).
>>
>> Visual Studio 2008 will generate a 2.0 assembly from 3.0 code.
>> Visual Studio 2005 will fail to build.
>>
>> As far as I really know.. the only reason to support Visual Studio
>> 2005 right now is for people who have Visual Studio 2005 Standard,
>> Pro, or Team licenses. Visual Studio 2008 Express is freely
>> downloadable and available and Mono is quite happy with 3.0 syntax
>>
>> Sincerely
>>
>> Teravus
>>
>> On 3/26/09, Frisby, Adam <adam at deepthink.com.au> wrote:
>> >
>> >
>> >
>> > If we consider a shift to .NET 3, I?d like to also propose utilizing the
> new
>> > Socket members that .NET 3 introduced ? there is some in there for high
>> > performance ASync socketing which perform significantly better than
> previous
>> > ones in the kinds of situations we employ.
>> >
>> >
>> >
>> > (As long as Mono 2.0.2 has those implemented of course ? but it
> shouldn?t be
>> > hard for the, they could at least just make them a splint to the old
>> > methods)
>> >
>> >
>> >
>> > Adam
>> >
>> >
>> >
>> >
>> >
>> > From: opensim-dev-bounces at lists.berlios.de
>> > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
>> > Ruud Lathrop
>> > Sent: Wednesday, 25 March 2009 11:34 AM
>> > To: opensim-dev at lists.berlios.de
>> > Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
>> >
>> >
>> >
>> >
>> > Visual Studio 2005 is using .NET 2.0/C# 2, only with some extending can
> you
>> > use some .NET 3/C# 3 features (WCF is the best known).
>> >
>> > It seems that Visual Studio 2008 is doing some tricks for you when you
> have
>> > a .NET 2.0 project, but use .NET 3/3.5 syntax. Like this:
>> >
>> > public string Test { get; set; }
>> >
>> > Just works in a .NET 2.0 project, same with lambda, while it is .NET 3/
> C# 3
>> > specs
>> >
>> > Ruud
>> >
>> >
>> >
>> > On Wed, Mar 25, 2009 at 3:57 PM, Teravus Ovares <teravus at gmail.com>
> wrote:
>> >
>> > The problem with Lamda Expressions isn't compiling to IL 2.0.. it's
>> > compiling in Visual Studio 2005. Visual Studio 2005 will not compile
>> > Lamda Expressions at all.
>> >
>> > Regards
>> >
>> > Teravus
>> >
>> >
>> >
>> > On 3/25/09, Sean Dague <sdague at gmail.com> wrote:
>> > > Stefan Andersson wrote:
>> > > > Yo.
>> > > >=20
>> > > > =20
>> > > >=20
>> > > > Feeling a bit stupid here, but just realized that many C# 3.0
> features =
>> > > (lambda expressions and inferred types, for example) compiles just
> fine t=
>> > > o the .Net 2 IL, so in practise, it can be used if the installed csc
> supp=
>> > > orts it.
>> > > >=20
>> > > > =20
>> > > >=20
>> > > > What I'm saying is that we can probably start using some C# 3.0
> feature=
>> > > s already even on mono (I guess) without moving from .Net 2.0.
> Question i=
>> > > s, what features?
>> > > >=20
>> > > >=20
>> > > > Could any mono person have a look at what C# 3.0 constructs are
> actuall=
>> > > y backwards compatible with .Net 2.0 on mono?
>> > >
>> > > One approach would be to make a new unit test that used some of those
>> > > features, then it would be easy for people to test with their
>> > > environment. I suspect mono 1.9.1 is still going to have issues, and
> we
>> > > haven't committed to dumping it yet (as that's what is shipping in the
>> > > latest stable release of Ubuntu, which a lot of people are using).
>> > >
>> > > The new Ubuntu release comes out in April with Mono 2.0.2, so we can
>> > > leave 1.9.1 behind in the near future.
>> > >
>> > > -Sean
>> > >
>> > > --=20
>> > > Sean Dague / Neas Bade
>> > > sdague at gmail.com
>> > > http://dague.net
>> > >
>> > >
>> > >
>> >
>> > > _______________________________________________
>> > > Opensim-dev mailing list
>> > > Opensim-dev at lists.berlios.de
>> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> > >
>> > >
>> > >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-devNo virus found in
> this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.11.22/2015 - Release Date: 03/24/09
> 16:00:00
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://lists.berlios.de/pipermail/opensim-dev/attachments/20090413/4939029b
> /attachment.html
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> End of Opensim-dev Digest, Vol 20, Issue 35
> *******************************************
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
More information about the Opensim-dev
mailing list