[sldev] alternative os support?

[Jesse Malthus]

This is entirely a moot point. All of the below should be done with
version number (Granted, announcing a Mac-only optional update is a
situation in which this would be required, but noone lies and says
they're a Mac). If you patch an exploit/DoS bug/make a protocol
change, the patch version (at least) should increase and the login
server denies access based on version number.

On 1/23/07, Joshua Bell <josh at secondlife.com> wrote:
> One current use of this handshake is to be able to say "there is a newer
> viewer version available for your platform" - either required or optional.
> * Optional usually indicates that bug fixes are available
> * Required usually indicates:
> ** a protocol change
> ** a client-side exploit was discovered/patched
> ** a bug in the viewer is causing content loss or DoSing the grid
>
> Obviously, viewers can lie, in which case:
>
> * They won't be told of optional updates - well duh, it's not an
> official build anyway
> * They would be using an incompatible protocol - and stop working in
> short order
> * They would be vulnerable to a client-side exploit - so update to the
> latest code
> * They would continue to DoS the grid - but a malicious viewer can do
> this anyway
>
> As the Second Life ecosystem evolves I presume that some day the
> viewer/server protocol will be open and stable enough that most of these
> issues go away and that this sort of handshake is informational only.
> And then some day this will hopefully be like the web, where the thought
> of a web site telling you to upgrade your browser is anathema.  However
> we're not there now, all but a small fraction of residents get their
> viewers from a single source, and the protocol does change on a frequent
> basis. So this handshake still makes sense.
>
> We'll hardly ever do server-side differentiation based on viewer
> platform. We have done this a few times recently when there was a
> Mac-only fix - no point in forcing the Windows users to update.
> (Following this thread, you'll see that we are currently unable to do
> that distinction for Windows vs. Linux users - sorry!) Generally, the
> optional/required versions advance in lockstep.
>
> ...
>
> So yes, we wouldn't add "bsd" to the list of valid clients, and should
> instead evolve this handshake to accommodate viewers build by other
> parties. Off the top of my head for short-term approaches would be to
> add Linux (which for the foreseeable future will be the UN*Xy platform
> targeted by Linden builds) and perhaps add an "other" token of some
> variety that can be used to tell users who have built their own viewers
> that the protocol has changed.
>
> Opinions? What makes sense? What information should be provided in this
> handshake such that a sufficient warning can be shown? (And consider the
> scenario that you've built the viewer yourself vs. the future scenario
> of having downloaded the viewer from a third party provider.)
>
> Mathew Frank wrote:
> > Joshua,
> > as long as this is being visited, the following thoughts occur:
> >
> >    1. blocking access based on reported name of client is like
> >       blocking based  on reported name of web browser - ie useless in
> >       blocking access to somebody not using your official client.   It
> >       only leads to a misreporting of the client type - for example
> >       libsecondlife says it is windows when it is not.
> >    2. I see that you put this in so as to have an easy answer to
> >       potential problems.
> >
> > Accordingly don't just add "bsd" to a list of valid clients.  Replace
> > the "denied access" system with a simple warning.
> >
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>


-- 
--Jesse