From enuslinden at gmail.com Mon Dec 1 09:48:53 2008 From: enuslinden at gmail.com (Aaron Terrell (Enus)) Date: Mon Dec 1 09:48:59 2008 Subject: [sldev] When does maint-viewer get merged? In-Reply-To: <4931DE5A.9000204@lindenlab.com> References: <1227998120.16230.4.camel@domino-laptop> <4931D597.6000006@lindenlab.com> <4931DE5A.9000204@lindenlab.com> Message-ID: correctamundo, expect to see this in release (trunk) now-ish, and in the 1.23RC. wrt tracking what is where when, why and how, there's a little pixie dust involved, but no whiteboard. Mostly, jira wizardry reveals the master plan, and a few white haired schedule trackers moving things along. ~e On Sat, Nov 29, 2008 at 4:29 PM, Rob Lanphier wrote: > On 11/29/2008 03:51 PM, Rob Lanphier wrote: > > More generally, maint-viewer-* branches get merged into the trunk > > periodically, and release candidate branches get branched from the trunk > > periodically, so it can sometimes take a while before a branch that gets > > merged in actually finds its way into a release. For example, the > > reason why changes from maint-viewer-11 aren't in 1.22 is that the 1.22 > > branch from trunk occurred before the maint-viewer-11 merge into the > > trunk occurred. > > > > > One correction: maint-viewer-11 isn't *yet* merged into trunk, but will > be very soon. Barring some horrific turn of events, it will almost > certainly make it into the 1.23 series. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081201/85973cc5/attachment-0001.htm From soft at lindenlab.com Wed Dec 3 08:53:03 2008 From: soft at lindenlab.com (Soft) Date: Wed Dec 3 08:53:06 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Open Source Meeting Thu 2pm - Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From chaosstar at gmail.com Wed Dec 3 11:01:38 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Dec 3 11:01:42 2008 Subject: [sldev] Missing OpenAL Library files after trunk update. Message-ID: <9bb32d430812031101l3460d813p19aeab4ab3429370@mail.gmail.com> Greetings! Just wanted to let you know, after the trunk update with the new OpenAL implementation, it seems like the actual OpenAL library files are missing. CMake does not grab them, nor are they in the lib package. See the missing \libraries\include\AL folder/directory. Currently you will have to grab the openAL source manually. --Chalice Yao From chaosstar at gmail.com Wed Dec 3 11:12:52 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Dec 3 11:12:55 2008 Subject: [sldev] Re: Missing OpenAL Library files after trunk update. In-Reply-To: <9bb32d430812031101l3460d813p19aeab4ab3429370@mail.gmail.com> References: <9bb32d430812031101l3460d813p19aeab4ab3429370@mail.gmail.com> Message-ID: <9bb32d430812031112y75b8e68eh4dfeeb00d3a65a07@mail.gmail.com> Sorry, I have to correct myself. The issue is one of alut.h including alc.h and al.h in the following manner: #include #include Which of course results in the building process not finding the files as \AL is not in the include paths of the project. It needs to be added. Another error that arises after the fix is LLAudioEngine_OpenAL::WIND_BUFFER_SIZE_SEC not being initialized in the class in the line 75 of audioengine_openal.h static const float WIND_BUFFER_SIZE_SEC = 0.05f; // 1/20th sec Sorry for the confusion if I caused any. On Wed, Dec 3, 2008 at 20:01, Ambrosia wrote: > Greetings! > > Just wanted to let you know, after the trunk update with the new > OpenAL implementation, it seems like the actual OpenAL library files > are missing. > > CMake does not grab them, nor are they in the lib package. > > See the missing \libraries\include\AL folder/directory. Currently you > will have to grab the openAL source manually. > > --Chalice Yao > From chaosstar at gmail.com Wed Dec 3 12:20:55 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Dec 3 12:21:00 2008 Subject: [sldev] Re: Missing OpenAL Library files after trunk update. In-Reply-To: <9bb32d430812031112y75b8e68eh4dfeeb00d3a65a07@mail.gmail.com> References: <9bb32d430812031101l3460d813p19aeab4ab3429370@mail.gmail.com> <9bb32d430812031112y75b8e68eh4dfeeb00d3a65a07@mail.gmail.com> Message-ID: <9bb32d430812031220y6ea32ca3n9bb4fab0b09a796a@mail.gmail.com> Addition: openal.lib, openal.dll, alut.lib and alit.dll are missing from the trunk. OpenAL dll and lib can be compiled from the source at http://kcat.strangesoft.net/openal.htm Alut can be grabbed as a binary release at openal.org Also, the viewer is trying to link fmodvc.lib into the secondlife-bin project despite being compiled with OpenAL. On Wed, Dec 3, 2008 at 20:12, Ambrosia wrote: > Sorry, I have to correct myself. > > The issue is one of alut.h including alc.h and al.h in the following manner: > > #include > #include > > Which of course results in the building process not finding the files > as \AL is not in the include paths of the project. It needs to be > added. > > Another error that arises after the fix is > LLAudioEngine_OpenAL::WIND_BUFFER_SIZE_SEC not being initialized in > the class in the line 75 of audioengine_openal.h > > static const float WIND_BUFFER_SIZE_SEC = 0.05f; // 1/20th sec > > > Sorry for the confusion if I caused any. > > On Wed, Dec 3, 2008 at 20:01, Ambrosia wrote: >> Greetings! >> >> Just wanted to let you know, after the trunk update with the new >> OpenAL implementation, it seems like the actual OpenAL library files >> are missing. >> >> CMake does not grab them, nor are they in the lib package. >> >> See the missing \libraries\include\AL folder/directory. Currently you >> will have to grab the openAL source manually. >> >> --Chalice Yao >> > From tofu.linden at lindenlab.com Wed Dec 3 12:37:01 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Wed Dec 3 12:36:04 2008 Subject: [sldev] Re: Missing OpenAL Library files after trunk update. In-Reply-To: <9bb32d430812031220y6ea32ca3n9bb4fab0b09a796a@mail.gmail.com> References: <9bb32d430812031101l3460d813p19aeab4ab3429370@mail.gmail.com><9bb32d430812031112y75b8e68eh4dfeeb00d3a65a07@mail.gmail .com> <9bb32d430812031220y6ea32ca3n9bb4fab0b09a796a@mail.gmail.com> Message-ID: <4936EDED.9010509@lindenlab.com> Thanks for trying this. This outcome does not seem terribly surprising - we only have a pre-made OpenAL package for Linux builds, since we use OpenAL only for official Linux builds - OpenAL on OSX/Win32 isn't something we deploy ourselves so builders are expected to have their own AL libs/headers on those platforms. It's also not been particularly tested yet on Win32/OSX either for similar reasons - any patches to make the tri-platform build smoother would be welcome! -Tofu Ambrosia wrote: > Addition: > > openal.lib, openal.dll, alut.lib and alit.dll are missing from the > trunk. OpenAL dll and lib can be compiled from the source at > http://kcat.strangesoft.net/openal.htm > Alut can be grabbed as a binary release at openal.org > > Also, the viewer is trying to link fmodvc.lib into the secondlife-bin > project despite being compiled with OpenAL. > > On Wed, Dec 3, 2008 at 20:12, Ambrosia wrote: >> Sorry, I have to correct myself. >> >> The issue is one of alut.h including alc.h and al.h in the following manner: >> >> #include >> #include >> >> Which of course results in the building process not finding the files >> as \AL is not in the include paths of the project. It needs to be >> added. >> >> Another error that arises after the fix is >> LLAudioEngine_OpenAL::WIND_BUFFER_SIZE_SEC not being initialized in >> the class in the line 75 of audioengine_openal.h >> >> static const float WIND_BUFFER_SIZE_SEC = 0.05f; // 1/20th sec >> >> >> Sorry for the confusion if I caused any. >> >> On Wed, Dec 3, 2008 at 20:01, Ambrosia wrote: >>> Greetings! >>> >>> Just wanted to let you know, after the trunk update with the new >>> OpenAL implementation, it seems like the actual OpenAL library files >>> are missing. >>> >>> CMake does not grab them, nor are they in the lib package. >>> >>> See the missing \libraries\include\AL folder/directory. Currently you >>> will have to grab the openAL source manually. >>> >>> --Chalice Yao >>> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From sarah77 at gmail.com Wed Dec 3 18:57:29 2008 From: sarah77 at gmail.com (Sarah) Date: Wed Dec 3 18:57:31 2008 Subject: [sldev] sarah77@gmail.com has invited you to have a 3D avatar chat Message-ID: <200812040257.mB42vTi0030842@AF001214.prod.imvu.com> From: Sarah Avatar: Guest_kidmarmite To: Sldev Hey Sldev,Sarah has added you as a friend on IMVU. Is Sarah your friend? Yes   No Please respond or Sarah may think you said no :) IMVU is the world's greatest 3D chat! Dress up your Avatar with 3D clothes. Chat with your friends & meet new ones. Decorate your own 3D Room with furniture. FREE to download & use! http://www.imvu.com Copyright © 2006-2007 IMVU, Inc. 411 High Street, Palo Alto, CA 94301. This email was sent via IMVU by Sarah (sarah77@gmail.com) to sldev@lists.secondlife.com. If you want to prevent any future emails from IMVU, you can remove yourself by pointing your web browser to http://www.imvu.com/catalog/web_nonregisteredoptout.php?code=6ad11c&email=sldev@lists.secondlife.com. Your unsubscribe confirmation code is 6ad11c -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081203/a12cbcc8/attachment.htm From karen.chow at clicksandlinks.com Thu Dec 4 01:50:40 2008 From: karen.chow at clicksandlinks.com (karen.chow) Date: Thu Dec 4 01:51:11 2008 Subject: [sldev] [HELP] How do I create an installer/setup file? Message-ID: <20081204095109.36F5E41B1F5@stupor.lindenlab.com> Hi, I have made some changes to the SL viewer source code and successfully compiled it using Visual C++ 2005 Express Edition. I have followed the wiki to compile my code, and I have built it using RelWithDebInfo, and my startup project is secondlife-bin. How do I create an installer/setup file for my viewer? Also, which files do I need to include with my installer/setup file? (I'm not actually looking to distribute this at the moment - so no issues with licenses, just want to know how I would do it.) Also, when I double-click on secondlife-bin.exe, I get the error below. Is this not the exe file for my compiled code? It runs if I use the debug option on Visual C++ 2005 Express Edition. ERROR: LLAppViewer::initConfiguration: Cannot load default configuration file C:\...\linden\indra\build-VC80\newview\relwithdebinfo\app_settings\settings_ files.xml I have not been able to find any information on what to do after I have compiled my code. Karen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081204/d98309b1/attachment.htm From chaosstar at gmail.com Thu Dec 4 02:17:00 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Dec 4 02:17:04 2008 Subject: [sldev] [HELP] How do I create an installer/setup file? In-Reply-To: <20081204095109.36F5E41B1F5@stupor.lindenlab.com> References: <20081204095109.36F5E41B1F5@stupor.lindenlab.com> Message-ID: <9bb32d430812040217i69c42b0eg63f0c1c14b6d727c@mail.gmail.com> On Thu, Dec 4, 2008 at 10:50, karen.chow wrote: > Hi, > > > > I have made some changes to the SL viewer source code and successfully > compiled it using Visual C++ 2005 Express Edition. I have followed the wiki > to compile my code, and I have built it using RelWithDebInfo, and my startup > project is secondlife-bin. How do I create an installer/setup file for my > viewer? Also, which files do I need to include with my installer/setup file? Try this: http://www.innosetup.com/isinfo.php > Also, when I double-click on secondlife-bin.exe, I get the error below. Is > this not the exe file for my compiled code? It runs if I use the debug > option on Visual C++ 2005 Express Edition. > > > > ERROR: LLAppViewer::initConfiguration: Cannot load default configuration > file > > C:\...\linden\indra\build-VC80\newview\relwithdebinfo\app_settings\settings_files.xml > Basically, after compiling, do the following: * copy all files in C:\...\linden\indra\build-VC80\newview\relwithdebinfo\* into a shiny new folder somewhere on your harddrive. * from the indra\newview folder, copy the following: - all .dll files - the skins, character, app_settings and fonts folders - all .txt files that have the word 'feature' in them. should be 5 or 6. Change to that folder and try again :> Basically after a compile, the files aren't quite yet where they should be for running the viewer. Note: you can't pack and distribute your viewer with llkdu.dll, the fonts folder, and anything *vivox* If you want to run the viewer from -within- visual studio (green arrow icon thingie), you need to copy the above files from the indra\newview into the C:\...\linden\indra\build-VC80\newview\ folder, and after clicking said icon select the secondlife-bin.exe in your \relwithdebinfo\ folder. Hope that helps. From kakurady at gmail.com Thu Dec 4 06:21:19 2008 From: kakurady at gmail.com (=?UTF-8?B?5Y2h5bqT5ouJ6L+q?=) Date: Thu Dec 4 06:21:50 2008 Subject: [sldev] [HELP] How do I create an installer/setup file? In-Reply-To: <20081204095109.36F5E41B1F5@stupor.lindenlab.com> References: <20081204095109.36F5E41B1F5@stupor.lindenlab.com> Message-ID: <4937E75F.8060805@gmail.com> nsis.sourceforge.net This is what Lindens use. It's Open-Source and Free Software, but the script used to compile the installer looks like some hybrid between BASIC and assembly. I've never needed any installer, so I'm not sure if it would be hard to use NSIS. Geneko > > Hi, > > > > I have made some changes to the SL viewer source code and successfully > compiled it using Visual C++ 2005 Express Edition. I have followed the > wiki to compile my code, and I have built it using RelWithDebInfo, and > my startup project is secondlife-bin. How do I create an > installer/setup file for my viewer? Also, which files do I need to > include with my installer/setup file? > > (I?m not actually looking to distribute this at the moment ? so no > issues with licenses, just want to know how I would do it.) > > > > Also, when I double-click on secondlife-bin.exe, I get the error > below. Is this not the exe file for my compiled code? It runs if I use > the debug option on Visual C++ 2005 Express Edition. > > > > ERROR: LLAppViewer::initConfiguration: Cannot load default > configuration file > > C:\...\linden\indra\build-VC80\newview\relwithdebinfo\app_settings\settings_files.xml > > > > I have not been able to find any information on what to do after I > have compiled my code. > > > > Karen > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081204/5dc2b877/attachment.htm From monkowsk at watson.ibm.com Thu Dec 4 08:58:37 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Dec 4 08:59:13 2008 Subject: [sldev] [HELP] How do I create an installer/setup file? In-Reply-To: <20081204095109.36F5E41B1F5@stupor.lindenlab.com> References: <20081204095109.36F5E41B1F5@stupor.lindenlab.com> Message-ID: <49380C3D.8050600@watson.ibm.com> karen.chow wrote: > Also, when I double-click on secondlife-bin.exe, I get the error below. > Is this not the exe file for my compiled code? It runs if I use the > debug option on Visual C++ 2005 Express Edition. > > ERROR: LLAppViewer::initConfiguration: Cannot load default configuration > file > > C:\...\linden\indra\build-VC80\newview\relwithdebinfo\app_settings\settings_files.xml I usually run in the directory of the installed SecondLife viewer. It saves all of the copying of files. The easiest way to do that is to set up a shortcut to your secondlife-bin.exe and modify the properties of the shortcut to run in c:\Program Files\SecondLife, then double-click on the shortcut. Mike From gareth at litesim.com Thu Dec 4 10:01:24 2008 From: gareth at litesim.com (Gareth Nelson) Date: Thu Dec 4 10:01:26 2008 Subject: [sldev] sarah77@gmail.com has invited you to have a 3D avatar chat In-Reply-To: <200812040257.mB42vTi0030842@AF001214.prod.imvu.com> References: <200812040257.mB42vTi0030842@AF001214.prod.imvu.com> Message-ID: <61dbdd7d0812041001q578455a2g8cdf38f004d827de@mail.gmail.com> Only 1 word for this: Wow On Thu, Dec 4, 2008 at 2:57 AM, Sarah wrote: > > From: Sarah > Avatar: Guest_kidmarmite > To: Sldev > > Hey Sldev, > > Sarah has added you as a friend on IMVU. > > Is Sarah your friend? > > Yes No > > Please respond or Sarah may think you said no :) > > IMVU is the world's greatest 3D chat! > > Dress up your Avatar with 3D clothes. > Chat with your friends & meet new ones. > Decorate your own 3D Room with furniture. > FREE to download & use! > > http://www.imvu.com > > Copyright (c) 2006-2007 IMVU, Inc. 411 High Street, Palo Alto, CA 94301. > > This email was sent via IMVU by Sarah (sarah77@gmail.com) to > sldev@lists.secondlife.com. > If you want to prevent any future emails from IMVU, you can remove yourself > by pointing your web browser to > http://www.imvu.com/catalog/web_nonregisteredoptout.php?code=6ad11c&email=sldev@lists.secondlife.com. > Your unsubscribe confirmation code is 6ad11c > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From sarah77 at gmail.com Thu Dec 4 10:40:13 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Thu Dec 4 10:40:17 2008 Subject: [sldev] sarah77@gmail.com has invited you to have a 3D avatar chat In-Reply-To: <61dbdd7d0812041001q578455a2g8cdf38f004d827de@mail.gmail.com> References: <200812040257.mB42vTi0030842@AF001214.prod.imvu.com> <61dbdd7d0812041001q578455a2g8cdf38f004d827de@mail.gmail.com> Message-ID: <9010c35c0812041040v28d37d26tc598eadfd41bb664@mail.gmail.com> My apologies, all. I was doing some research and when setting up an acct with IMVU, it asked if I wanted to look for friends in my contacts. Instead of just looking, it emailed everyone. Fail. :( - Sarah On Thu, Dec 4, 2008 at 1:01 PM, Gareth Nelson wrote: > Only 1 word for this: > Wow > > On Thu, Dec 4, 2008 at 2:57 AM, Sarah wrote: > > > > From: Sarah > > Avatar: Guest_kidmarmite > > To: Sldev > > > > Hey Sldev, > > > > Sarah has added you as a friend on IMVU. > > > > Is Sarah your friend? > > > > Yes No > > > > Please respond or Sarah may think you said no :) > > > > IMVU is the world's greatest 3D chat! > > > > Dress up your Avatar with 3D clothes. > > Chat with your friends & meet new ones. > > Decorate your own 3D Room with furniture. > > FREE to download & use! > > > > http://www.imvu.com > > > > Copyright (c) 2006-2007 IMVU, Inc. 411 High Street, Palo Alto, CA 94301. > > > > This email was sent via IMVU by Sarah (sarah77@gmail.com) to > > sldev@lists.secondlife.com. > > If you want to prevent any future emails from IMVU, you can remove > yourself > > by pointing your web browser to > > > http://www.imvu.com/catalog/web_nonregisteredoptout.php?code=6ad11c&email=sldev@lists.secondlife.com > . > > Your unsubscribe confirmation code is 6ad11c > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081204/e8e5e964/attachment.htm From soft at lindenlab.com Thu Dec 4 13:57:11 2008 From: soft at lindenlab.com (Soft) Date: Thu Dec 4 13:57:13 2008 Subject: [sldev] stereoscopic status and Becoming Dragon, a 365 hour performance in Second Life In-Reply-To: <1e0ce1090811302228m61f74aa2mb96af99cbb70914a@mail.gmail.com> References: <1e0ce1090811291953v49821ddcj2a482a942726f875@mail.gmail.com> <4932AED2.3080508@gmx.net> <49333AEC.2090608@gmx.net> <1e0ce1090811302228m61f74aa2mb96af99cbb70914a@mail.gmail.com> Message-ID: Which version of the viewer are you using for your work? The last patch attached to the JIRA is in a pre-Windlight viewer. If someone's done work in 1.21 or later, it's worth trying to ramp up internal involvement. On Mon, Dec 1, 2008 at 12:28 AM, azdel slade wrote: > good news, we actually got it working tonight, using the latest quadro > driver and code similar to the umich patch! we'll be posting a patch > soon! > > but, i still have one problem that's pretty big for me and my > performance, which is that quicktime video objects cause the stereo > code to crash. any ideas on how to fix that? so i can see who's in the > real lab the whole time i'm in sl? > > thanks, > > azdel > > > On Sun, Nov 30, 2008 at 5:16 PM, Carsten Juttner wrote: >> Carsten Juttner wrote: >>> >>> We used anaglyph rendering with some LCD shutter glasses and a huge Barco >>> projector. >> >> Just noticed something got lost here, I meant to write we did *not* use >> anaglyph rendering but LCD shutter glasses. >> The end result is of course he same. >> >> Hope you find the cause for the crash, at least you now get the correct >> context which should make things easier. >> >> >> Carsten >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From dnbyena at gmail.com Thu Dec 4 22:28:46 2008 From: dnbyena at gmail.com (Khyota) Date: Thu Dec 4 22:29:11 2008 Subject: [sldev] Easier window resize to custom resolutions? Message-ID: <200812050128.47461.dnbyena@gmail.com> Really want to be able to type the rez i want in the window size box. http://jira.secondlife.com/browse/VWR-10890 Feallight Hellershanks submitted a patch that would allow text input in it but the C++ code still ignores it Wonder if anyone else would find this a usefull feature to implement. The window size box doesnt work at all in window mode on linux, hopefully we can get that one knocked out as well. http://jira.secondlife.com/browse/VWR-9257 It could be a really simple fix Khyota From matthew.dowd at hotmail.co.uk Fri Dec 5 01:49:48 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Dec 5 01:49:50 2008 Subject: [sldev] Open Source Meeting Thu 2pm In-Reply-To: References: Message-ID: Re VWR-2681 - Populate the Resident Chooser list with avatars within chat distanceI note that this was triaged yesterday. Sorry for the delay on this - I'm afraid I've been concentrating on various RL things over the last six months (the usual overworked, understaffed things, and the fact that house maintenance things seem to happen all at once etc....) Hopefully I'll have a chance to pull the code out of mothballs and finish it over the Christmas break (the day job doesn't involve coding, so coding is now a relaxation!!).I note from the minutes of an earlier triage that someone was supposed to have IM'ed me in world. Needless to say no IM ever arrived (and IMs are set to go to my e-mail) so I suspect the SL IM bugmonster ate it.Matthew> Date: Wed, 3 Dec 2008 10:53:03 -0600> From: soft@lindenlab.com> To: sldev@lists.secondlife.com> Subject: [sldev] Open Source Meeting Thu 2pm> > Open Source Meeting Thu 2pm - Our Thursday open source meetings take> place at 2pm. If there is anything you would like on the agenda...> have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda> _______________________________________________> Policies and (un)subscribe information available here:> http://wiki.secondlife.com/wiki/SLDev> Please read the policies before posting to keep unmoderated posting privileges _________________________________________________________________ Get Windows Live Messenger on your Mobile http://clk.atdmt.com/UKM/go/msnnkmgl0010000001ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081205/0a70dc52/attachment.htm From soft at lindenlab.com Fri Dec 5 06:36:15 2008 From: soft at lindenlab.com (Soft) Date: Fri Dec 5 06:38:25 2008 Subject: [sldev] Open Source Meeting Thu 2pm In-Reply-To: References: Message-ID: Very cool! You've probably seen in the JIRA comments - RX is in a comfortable place with the feature. And frankly I can think of a few times since first seeing this when I wish I'd had the feature myself. It will be great to have this. On Fri, Dec 5, 2008 at 3:49 AM, Matthew Dowd wrote: > Re VWR-2681 - Populate the Resident Chooser list with avatars within chat > distance > I note that this was triaged yesterday. Sorry for the delay on this - I'm > afraid I've been concentrating on various RL things over the last six months > (the usual overworked, understaffed things, and the fact that house > maintenance things seem to happen all at once etc....) Hopefully I'll have a > chance to pull the code out of mothballs and finish it over the Christmas > break (the day job doesn't involve coding, so coding is now a relaxation!!). > I note from the minutes of an earlier triage that someone was supposed to > have IM'ed me in world. Needless to say no IM ever arrived (and IMs are set > to go to my e-mail) so I suspect the SL IM bugmonster ate it. > Matthew > > > >> Date: Wed, 3 Dec 2008 10:53:03 -0600 >> From: soft@lindenlab.com >> To: sldev@lists.secondlife.com >> Subject: [sldev] Open Source Meeting Thu 2pm >> >> Open Source Meeting Thu 2pm - Our Thursday open source meetings take >> place at 2pm. If there is anything you would like on the agenda... >> have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > ________________________________ > Read amazing stories to your kids on Messenger. Try it Now! From monkowsk at watson.ibm.com Fri Dec 5 08:33:12 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Dec 5 08:33:16 2008 Subject: [sldev] Magical scripted HUD/UI Message-ID: <493957C8.8030904@watson.ibm.com> If anyone is looking for a project that will make you a hero, see http://jira.secondlife.com/browse/VWR-10924 Mike Mm Alder From kerdezixe at gmail.com Sun Dec 7 08:56:05 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sun Dec 7 08:56:14 2008 Subject: [sldev] Re: Some "benchmark/profiling" with new computer stuff. In-Reply-To: <8a1bfe660811181651y1ff626f0ib44d54a33959bc02@mail.gmail.com> References: <8a1bfe660811181651y1ff626f0ib44d54a33959bc02@mail.gmail.com> Message-ID: <8a1bfe660812070856i102dc982rbe2a527edf777939@mail.gmail.com> 2008/11/19 Laurent Laborde : > > 1 gigabyte i-ram loaded with 4GB of ram. > It's a wonderfull pci-card with a sata controler on it, and 8 ram > slot, instead of hard drive disk. > that mean : ram based "hard drive", insane I/O performance. > Of course, i put the SL Cache on it. If you're interested by that kind of stuff, hyperos system launched their new hyperdrive 5, which is much much cheaper than the version 4, and do not require ECC ram anymore :) http://www.hyperossystems.co.uk/ I haven't tested it yet. We use the i-ram at work, if we decide to try the HD5, i'll keep you updated about the performances. -- F4FQM Kerunix Flan Laurent Laborde From secret.argent at gmail.com Sun Dec 7 09:36:53 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Dec 7 09:37:16 2008 Subject: [sldev] Magical scripted HUD/UI In-Reply-To: <493957C8.8030904@watson.ibm.com> References: <493957C8.8030904@watson.ibm.com> Message-ID: <8BC817E3-7F27-43CF-8236-4340CBF83063@gmail.com> If we're going to toss ideas out here... here's a much simpler approach that will provide the same kind of functionality: http://jira.secondlife.com/browse/SVC-1594 From monkowsk at watson.ibm.com Mon Dec 8 07:43:04 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Dec 8 07:43:13 2008 Subject: [sldev] Magical scripted HUD/UI In-Reply-To: <8BC817E3-7F27-43CF-8236-4340CBF83063@gmail.com> References: <493957C8.8030904@watson.ibm.com> <8BC817E3-7F27-43CF-8236-4340CBF83063@gmail.com> Message-ID: <493D4088.60304@watson.ibm.com> You're providing a different kind of functionality there. SVC-1594 would allow you to do anything that can be done in a web browser using web services plus send chat messages to an in-world object. VWR-10924 would allow you to do anything that can be done in the SL viewer using callbacks plus send chat messages to an in-world object. Mike Argent Stonecutter wrote: > If we're going to toss ideas out here... here's a much simpler approach > that will provide the same kind of functionality: > > http://jira.secondlife.com/browse/SVC-1594 From phli.foxchase at gmail.com Mon Dec 8 11:37:26 2008 From: phli.foxchase at gmail.com (Phli Foxchase) Date: Mon Dec 8 11:37:29 2008 Subject: [sldev] Login Failed again and again Message-ID: <388c3cc90812081137t29c04b54i18562bcdd39c0c73@mail.gmail.com> Hello, I would like to know if some problems persist in the login process. I help in a french forum and since last Friday, 3 residents can't connect with this message : *Login Failed .... The system is logging you out right now. Your account will not be available until ~ Pacific Time ... *I know this mailing list is not an official support but is there something wrong in the login process ?* *Thank you very much. Best regards. Phli Foxchase* * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081208/df389146/attachment.htm From carjay at gmx.net Mon Dec 8 14:46:51 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Dec 8 14:46:42 2008 Subject: [sldev] Login Failed again and again In-Reply-To: <388c3cc90812081137t29c04b54i18562bcdd39c0c73@mail.gmail.com> References: <388c3cc90812081137t29c04b54i18562bcdd39c0c73@mail.gmail.com> Message-ID: <493DA3DB.7080204@gmx.net> Phli Foxchase wrote: > *Login Failed .... The system is logging you out right now. Your > account will not be available until ~ Pacific Time ... > * Not nice :-| If this message occurs repeatedly with the "not be available until" - time extending forever that means their presence on SL did not get cleared (they got stuck). It's even possible you see their "ghosts" still in world. One trick is to try and send an instant message to them but that does not always help. Support should be able to reset the presence, of course, but for a basic account this may mean some time to wait (I had this once and the sim was reset before support ever responded). Another option could be to try and reset the sim they were in. Carsten From sllists at boroon.dasgupta.ch Mon Dec 8 15:29:07 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Dec 8 15:29:11 2008 Subject: [sldev] Login Failed again and again In-Reply-To: <493DA3DB.7080204@gmx.net> References: <388c3cc90812081137t29c04b54i18562bcdd39c0c73@mail.gmail.com> <493DA3DB.7080204@gmx.net> Message-ID: <493DADC3.1020700@boroon.dasgupta.ch> Carsten Juttner schrieb: > Support should be able to reset the presence, of course, but for a > basic account this may mean some time to wait (I had this once and the > sim was reset before support ever responded). Hmmm ... would be a nice expansion of http://jira.secondlife.com/browse/WEB-302 to able to do that yourself. What do you think? Like, when you're logged in on the secondlife.com website, a link that says "click here to be logged out of the agni grid". Of course it should display a warning before actually logging you out. cheers Boroondas From intertricity at gmail.com Mon Dec 8 16:35:25 2008 From: intertricity at gmail.com (intertricity@gmail.com) Date: Mon Dec 8 16:35:27 2008 Subject: [sldev] SL default camera lens angle? Message-ID: <0016361e892aca8e84045d92519b@google.com> I'm trying to match the perspective view in Blender to the Camera view of SL. I want to say that it seems like the camera angle seems to be 75 degrees, but I can't be sure. Does anybody have some insight on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081209/a7223446/attachment.htm From dnbyena at gmail.com Mon Dec 8 16:54:49 2008 From: dnbyena at gmail.com (Khyota) Date: Mon Dec 8 16:54:54 2008 Subject: [sldev] SL default camera lens angle? In-Reply-To: <0016361e892aca8e84045d92519b@google.com> References: <0016361e892aca8e84045d92519b@google.com> Message-ID: <200812081954.49396.dnbyena@gmail.com> On Monday 08 December 2008 07:35:25 pm intertricity@gmail.com wrote: > I'm trying to match the perspective view in Blender to the Camera view of > SL. I want to say that it seems like the camera angle seems to be 75 > degrees, but I can't be sure. Does anybody have some insight on this? llcamera.h says DEFAULT_FIELD_OF_VIEW = 60.f * DEG_TO_RAD; so im pretty sure its 60 :) From q at lindenlab.com Mon Dec 8 18:43:24 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon Dec 8 18:43:28 2008 Subject: [sldev] SL default camera lens angle? In-Reply-To: <200812081954.49396.dnbyena@gmail.com> References: <0016361e892aca8e84045d92519b@google.com> <200812081954.49396.dnbyena@gmail.com> Message-ID: That's only the original default. I'm not quite sure under what circumstances it can change, honestly. You can see the current FOV setting, though, if you use Advanced -> HUD Info -> FOV. Q On Dec 8, 2008, at 7:54 PM, Khyota wrote: > On Monday 08 December 2008 07:35:25 pm intertricity@gmail.com wrote: >> I'm trying to match the perspective view in Blender to the Camera >> view of >> SL. I want to say that it seems like the camera angle seems to be 75 >> degrees, but I can't be sure. Does anybody have some insight on this? > > > llcamera.h says DEFAULT_FIELD_OF_VIEW = 60.f * DEG_TO_RAD; > so im > pretty sure its 60 :) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From dnbyena at gmail.com Mon Dec 8 19:06:19 2008 From: dnbyena at gmail.com (Khyota) Date: Mon Dec 8 19:06:21 2008 Subject: [sldev] SL default camera lens angle? In-Reply-To: References: <0016361e892aca8e84045d92519b@google.com> <200812081954.49396.dnbyena@gmail.com> Message-ID: <200812082206.19717.dnbyena@gmail.com> On Monday 08 December 2008 09:43:24 pm you wrote: > That's only the original default. I'm not quite sure under what > circumstances it can change, honestly. > > You can see the current FOV setting, though, if you use Advanced -> > HUD Info -> FOV. > > Q > > On Dec 8, 2008, at 7:54 PM, Khyota wrote: > > On Monday 08 December 2008 07:35:25 pm intertricity@gmail.com wrote: > >> I'm trying to match the perspective view in Blender to the Camera > >> view of > >> SL. I want to say that it seems like the camera angle seems to be 75 > >> degrees, but I can't be sure. Does anybody have some insight on this? > > > > llcamera.h says DEFAULT_FIELD_OF_VIEW = 60.f * DEG_TO_RAD; > > so im > > pretty sure its 60 :) > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges you can change it by the zoom in/out options in the tools menu the current min is 0.1 RAD and max is PI RAD this is changed in featurettes-8 to fix VWR-5241 by changing the range to 5 -175 degrees :) From dnbyena at gmail.com Mon Dec 8 19:08:13 2008 From: dnbyena at gmail.com (Khyota) Date: Mon Dec 8 19:09:46 2008 Subject: [sldev] SL default camera lens angle? In-Reply-To: <200812082206.19717.dnbyena@gmail.com> References: <0016361e892aca8e84045d92519b@google.com> <200812082206.19717.dnbyena@gmail.com> Message-ID: <200812082208.13560.dnbyena@gmail.com> On Monday 08 December 2008 10:06:19 pm you wrote: > On Monday 08 December 2008 09:43:24 pm you wrote: > > That's only the original default. I'm not quite sure under what > > circumstances it can change, honestly. > > > > You can see the current FOV setting, though, if you use Advanced -> > > HUD Info -> FOV. > > > > Q > > > > On Dec 8, 2008, at 7:54 PM, Khyota wrote: > > > On Monday 08 December 2008 07:35:25 pm intertricity@gmail.com wrote: > > >> I'm trying to match the perspective view in Blender to the Camera > > >> view of > > >> SL. I want to say that it seems like the camera angle seems to be 75 > > >> degrees, but I can't be sure. Does anybody have some insight on this? > > > > > > llcamera.h says DEFAULT_FIELD_OF_VIEW = 60.f * DEG_TO_RAD; > > > so im > > > pretty sure its 60 :) > > > _______________________________________________ > > > Policies and (un)subscribe information available here: > > > http://wiki.secondlife.com/wiki/SLDev > > > Please read the policies before posting to keep unmoderated posting > > > privileges > > you can change it by the zoom in/out options in the tools menu > > the current min is 0.1 RAD and max is PI RAD > > this is changed in featurettes-8 to fix VWR-5241 by changing the range to > 5 -175 degrees :) Correction, thats the View menu. From secret.argent at gmail.com Tue Dec 9 05:40:40 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Dec 9 05:41:32 2008 Subject: [sldev] Magical scripted HUD/UI In-Reply-To: <493D4088.60304@watson.ibm.com> References: <493957C8.8030904@watson.ibm.com> <8BC817E3-7F27-43CF-8236-4340CBF83063@gmail.com> <493D4088.60304@watson.ibm.com> Message-ID: On 2008-12-08, at 09:43, Mike Monkowski wrote: > You're providing a different kind of functionality there. It's a different mechanism, but the basic functionality being provided is a richer dialog in the user interface, no? From monkowsk at watson.ibm.com Tue Dec 9 08:18:06 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Dec 9 08:18:14 2008 Subject: [sldev] Magical scripted HUD/UI In-Reply-To: References: <493957C8.8030904@watson.ibm.com> <8BC817E3-7F27-43CF-8236-4340CBF83063@gmail.com> <493D4088.60304@watson.ibm.com> Message-ID: <493E9A3E.2010404@watson.ibm.com> "richer dialog" is probably too vague. Specifically VWR-10924 provides two things. First, it allows the current UI widgets, with new callbacks, to be used for communicating with in-world objects using chat channels. Second, it allows the current UI widgets, using the current callbacks, to be rearranged to provide custom UI panels, menus, and floaters. In the second case, the purpose of the in-world object is just to define the new UI component. Mike Argent Stonecutter wrote: > On 2008-12-08, at 09:43, Mike Monkowski wrote: > >> You're providing a different kind of functionality there. > > > It's a different mechanism, but the basic functionality being provided > is a richer dialog in the user interface, no? From secret.argent at gmail.com Wed Dec 10 06:03:04 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 10 06:03:35 2008 Subject: [sldev] Magical scripted HUD/UI In-Reply-To: <493E9A3E.2010404@watson.ibm.com> References: <493957C8.8030904@watson.ibm.com> <8BC817E3-7F27-43CF-8236-4340CBF83063@gmail.com> <493D4088.60304@watson.ibm.com> <493E9A3E.2010404@watson.ibm.com> Message-ID: <0C2BEDC1-F642-49B9-90AA-1614FF1D6753@gmail.com> On 2008-12-09, at 10:18, Mike Monkowski wrote: > "richer dialog" is probably too vague. Specifically VWR-10924 > provides two things. First, it allows the current UI widgets, with > new callbacks, to be used for communicating with in-world objects > using chat channels. Second, it allows the current UI widgets, > using the current callbacks, to be rearranged to provide custom UI > panels, menus, and floaters. In the second case, the purpose of the > in-world object is just to define the new UI component. OK, you're talking about two separate use cases. I hadn't even thought of the second one, and I think it would be a lot more work than you're envisioning. The SL client XML schema seems to be heavily tied to the files, rather than having the callbacks driven from the XML directly. The extra work of creating a meta-language to define the callbacks outside that context, and managing interactions between components, is likely to scuttle the whole project. The first use case... an improved dialog mechanism... is much more easily accomplished via HTML. The XML schema is extremely primitive and hyper-specialized, and even modifying the current UI is much more work than creating a simple HTML form. From kakurady at gmail.com Wed Dec 10 10:06:30 2008 From: kakurady at gmail.com (Geneko Nemeth) Date: Wed Dec 10 10:06:45 2008 Subject: [sldev] Magical scripted HUD/UI In-Reply-To: <0C2BEDC1-F642-49B9-90AA-1614FF1D6753@gmail.com> References: <493957C8.8030904@watson.ibm.com> <8BC817E3-7F27-43CF-8236-4340CBF83063@gmail.com> <493D4088.60304@watson.ibm.com> <493E9A3E.2010404@watson.ibm.com> <0C2BEDC1-F642-49B9-90AA-1614FF1D6753@gmail.com> Message-ID: <49400526.3050900@gmail.com> I would like to toss this in here: http://wiki.secondlife.com/wiki/Client-side_Scripting_for_HUDs_and_Widgets In any case the objective is to move more HUD functionality to the client, since building them in-world is troublesome and its performance is at the mercy of the servers. HTML is good for documents and forms, but isn't really up to building a general interface. That didn't stop people making AJAX applications of course. (Note that an asynchronous communication with the server, similar to AJAX, might be handy.) On the other hand... XUI in its current form, is quite inflexible. This is on the Linden's roadmap, but last time we checked they were working on "secret projects". My personal wish is that improve XUI and add some kind of scripting support, so you could put XUI on in-world vendors, HUDs and viewer extension packages. But... we have a third option here. http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul Mozilla (now Seamonkey) and Firefox both implements their interface with XUL + JavaScript. And currently, the web browser embedded in Second Life client is based on Mozilla. That means... we have an existing long-used UI description language usable with the browser HUD. Now all you need to add is an client API into that. Of course, allowing HUDs to talk to the client and even to servers could lead to new security and privacy concerns. You don't want random pages on the interwebs to send chat spam, or lock the viewer up. Geneko Argent Stonecutter ??: > On 2008-12-09, at 10:18, Mike Monkowski wrote: >> "richer dialog" is probably too vague. Specifically VWR-10924 >> provides two things. First, it allows the current UI widgets, with >> new callbacks, to be used for communicating with in-world objects >> using chat channels. Second, it allows the current UI widgets, using >> the current callbacks, to be rearranged to provide custom UI panels, >> menus, and floaters. In the second case, the purpose of the in-world >> object is just to define the new UI component. > > OK, you're talking about two separate use cases. I hadn't even thought > of the second one, and I think it would be a lot more work than you're > envisioning. The SL client XML schema seems to be heavily tied to the > files, rather than having the callbacks driven from the XML directly. > The extra work of creating a meta-language to define the callbacks > outside that context, and managing interactions between components, is > likely to scuttle the whole project. > > The first use case... an improved dialog mechanism... is much more > easily accomplished via HTML. The XML schema is extremely primitive > and hyper-specialized, and even modifying the current UI is much more > work than creating a simple HTML form. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From soft at lindenlab.com Wed Dec 10 10:44:52 2008 From: soft at lindenlab.com (Soft) Date: Wed Dec 10 10:44:54 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From gareth at litesim.com Wed Dec 10 19:31:18 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Dec 10 19:31:21 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... Message-ID: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com> Surely there's more than this? 0 12-06-08 20:46 linden/ 0 12-06-08 20:46 linden/indra/ 0 12-06-08 20:46 linden/indra/newview/ 0 12-06-08 20:46 linden/indra/newview/fonts/ 55108 12-06-08 20:46 linden/indra/newview/fonts/MtBkLfRg.ttf 52444 12-06-08 20:46 linden/indra/newview/fonts/MtBdLfRg.ttf 56376 12-06-08 20:46 linden/indra/newview/fonts/profontwindows.ttf 14158 12-06-08 20:46 linden/indra/newview/fonts/profontdoc.txt 1226 12-06-08 20:46 linden/indra/newview/fonts/Readme.txt 38602 12-06-08 20:46 linden/LICENSE-libraries-win32.txt From dnbyena at gmail.com Wed Dec 10 20:21:39 2008 From: dnbyena at gmail.com (Khyota) Date: Wed Dec 10 20:21:44 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com> References: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com> Message-ID: <200812102321.39471.dnbyena@gmail.com> On Wednesday 10 December 2008 10:31:18 pm Gareth Nelson wrote: > Surely there's more than this? > 0 12-06-08 20:46 linden/ > 0 12-06-08 20:46 linden/indra/ > 0 12-06-08 20:46 linden/indra/newview/ > 0 12-06-08 20:46 linden/indra/newview/fonts/ > 55108 12-06-08 20:46 linden/indra/newview/fonts/MtBkLfRg.ttf > 52444 12-06-08 20:46 linden/indra/newview/fonts/MtBdLfRg.ttf > 56376 12-06-08 20:46 linden/indra/newview/fonts/profontwindows.ttf > 14158 12-06-08 20:46 linden/indra/newview/fonts/profontdoc.txt > 1226 12-06-08 20:46 linden/indra/newview/fonts/Readme.txt > 38602 12-06-08 20:46 linden/LICENSE-libraries-win32.txt > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges All the libs packages are like that now, Libs are downloaded automagicly when you build but idk how that works on win32. I really wish those lib packages would dissapear though. Made a jira issue if your interested. :) http://jira.secondlife.com/browse/VWR-9477 From kakurady at gmail.com Wed Dec 10 21:37:30 2008 From: kakurady at gmail.com (=?UTF-8?B?5Y2h5bqT5ouJ6L+q?=) Date: Wed Dec 10 21:37:46 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <200812102321.39471.dnbyena@gmail.com> References: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com> <200812102321.39471.dnbyena@gmail.com> Message-ID: <4940A71A.5040306@gmail.com> These are the proprietary Meta fonts bundled with and used in official releases of Second Life. They are not available under GPL, GPL-compatible or any Free Software licenses (although it seems possible to obtain a separate license for personal use only). So I'm afraid they are here to stay for the forseeable future. Although frankly let's replace it with DejaVu Condensed or one of the many nice Libre font families out there. Geneko Khyota ??: > On Wednesday 10 December 2008 10:31:18 pm Gareth Nelson wrote: > >> Surely there's more than this? >> 0 12-06-08 20:46 linden/ >> 0 12-06-08 20:46 linden/indra/ >> 0 12-06-08 20:46 linden/indra/newview/ >> 0 12-06-08 20:46 linden/indra/newview/fonts/ >> 55108 12-06-08 20:46 linden/indra/newview/fonts/MtBkLfRg.ttf >> 52444 12-06-08 20:46 linden/indra/newview/fonts/MtBdLfRg.ttf >> 56376 12-06-08 20:46 linden/indra/newview/fonts/profontwindows.ttf >> 14158 12-06-08 20:46 linden/indra/newview/fonts/profontdoc.txt >> 1226 12-06-08 20:46 linden/indra/newview/fonts/Readme.txt >> 38602 12-06-08 20:46 linden/LICENSE-libraries-win32.txt >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > All the libs packages are like that now, Libs are downloaded automagicly when > you build but idk how that works on win32. I really wish those lib packages > would dissapear though. Made a jira issue if your interested. :) > > http://jira.secondlife.com/browse/VWR-9477 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From tofu.linden at lindenlab.com Thu Dec 11 10:21:16 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Dec 11 10:21:21 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <4940A71A.5040306@gmail.com> References: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com><200812102321.39471.dnbyena@gmail.com> <4940A71A.5040306@gmail.com> Message-ID: <49415A1C.7060000@lindenlab.com> ???? wrote: > Although frankly let's replace it with DejaVu Condensed or one of the > many nice Libre font families out there. DejaVu might be a great option. Good license, and pretty good coverage for the file size. Any other suggestions? Changing our default font is a surprisingly large effort because of truncation issues, but I think it could be worth it (though the call isn't mine personally) - but we have to make a good font decision (ideally both a sans and a sansmono). From me at signpostmarv.name Thu Dec 11 11:50:49 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Thu Dec 11 11:50:32 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <49415A1C.7060000@lindenlab.com> References: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com><200812102321.39471.dnbyena@gmail.com> <4940A71A.5040306@gmail.com> <49415A1C.7060000@lindenlab.com> Message-ID: <49416F19.7050208@signpostmarv.name> What're the fonts that Imprudence is using in their viewer ? ~ Marv. Tofu Linden wrote: > ???? wrote: > >> Although frankly let's replace it with DejaVu Condensed or one of the >> many nice Libre font families out there. >> > > DejaVu might be a great option. Good license, and pretty good > coverage for the file size. Any other suggestions? > > Changing our default font is a surprisingly large effort because of > truncation issues, but I think it could be worth it (though the > call isn't mine personally) - but we have to make a good font > decision (ideally both a sans and a sansmono). > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081211/fd0bece7/smime.bin From gigstaggart at gmail.com Thu Dec 11 12:31:16 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Dec 11 12:31:19 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <49415A1C.7060000@lindenlab.com> References: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com><200812102321.39471.dnbyena@gmail.com> <4940A71A.5040306@gmail.com> <49415A1C.7060000@lindenlab.com> Message-ID: <49417894.7060706@gmail.com> Tofu Linden wrote: > ???? wrote: >> Although frankly let's replace it with DejaVu Condensed or one of the >> many nice Libre font families out there. > > DejaVu might be a great option. Good license, and pretty good > coverage for the file size. Any other suggestions? > > Changing our default font is a surprisingly large effort because of > truncation issues, but I think it could be worth it (though the > call isn't mine personally) - but we have to make a good font > decision (ideally both a sans and a sansmono). We are using DeJa in Meerkat and there are actually very few truncation issues. Here's the fonts: ./branches/branch-8.9/indra/newview/linux_tools/unicode.ttf ./branches/branch-8.9/indra/newview/fonts/DejaVuSansCondensed-Bold.ttf ./branches/branch-8.9/indra/newview/fonts/profontwindows.ttf ./branches/branch-8.9/indra/newview/fonts/DejaVuSansCondensed.ttf -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081211/7a4f3d69/smime.bin From dnbyena at gmail.com Thu Dec 11 12:37:45 2008 From: dnbyena at gmail.com (Khyota) Date: Thu Dec 11 12:38:06 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <49417894.7060706@gmail.com> References: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com> <49415A1C.7060000@lindenlab.com> <49417894.7060706@gmail.com> Message-ID: <200812111537.46096.dnbyena@gmail.com> On Thursday 11 December 2008 03:31:16 pm Jason Giglio wrote: > ./branches/branch-8.9/indra/newview/linux_tools/unicode.ttf > ./branches/branch-8.9/indra/newview/fonts/DejaVuSansCondensed-Bold.ttf > ./branches/branch-8.9/indra/newview/fonts/profontwindows.ttf > ./branches/branch-8.9/indra/newview/fonts/DejaVuSansCondensed.ttf hmm, havent seen a unicode.ttf in ages, what is it still used for in the meerkat viewer? From gigstaggart at gmail.com Thu Dec 11 12:50:28 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Dec 11 12:50:33 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <200812111537.46096.dnbyena@gmail.com> References: <61dbdd7d0812101931uf3cf55bgf26d43800f046813@mail.gmail.com> <49415A1C.7060000@lindenlab.com> <49417894.7060706@gmail.com> <200812111537.46096.dnbyena@gmail.com> Message-ID: <49417D14.1080507@gmail.com> Khyota wrote: > hmm, havent seen a unicode.ttf in ages, what is it still used for in the > meerkat viewer? Most likely nothing. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081211/e5519463/smime.bin From alissa_sabre at yahoo.co.jp Thu Dec 11 15:33:34 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Dec 11 15:33:42 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <49415A1C.7060000@lindenlab.com> References: <4940A71A.5040306@gmail.com> <49415A1C.7060000@lindenlab.com> Message-ID: <1ds4ds6LnPdsGe5918Q8n.alissa_sabre@yahoo.co.jp> Geneko: > Although frankly let's replace it with DejaVu Condensed or one of the > many nice Libre font families out there. Tofu: > DejaVu might be a great option. Good license, and pretty good > coverage for the file size. Any other suggestions? DejaVu is fine if we use Latin/Cyrillic/Greek only. Some scripts in DejaVu are very low quality. This is a well known fact, that even the DejaVu maintainer agrees on. They are intentionally adding garbages into the font because they believe it facilitate their goals. One of the reason they do so is that DejaVu assumes each user picks up parts of the DejaVu glyph collection and supplement some others with other fonts, using a flexible font synthesis system such as fontconfig, as his/her need. I believe the current SL font choosing system is too prmitive to use DejaVu properly. I would support the idea to use DejaVu if LL extracts Latin/Cyrillic/Greek (and some punctuation) portion of the font and use it. I'm not in favor of use of DejaVu as a whole. I see some problems of the current SL fonts. However, my fundamental question on the font is bit different: Do we really need a set of _SL_fonts_? Why not just use platform's standard font? I'm asking this because I see no big advantage to do so, and I see several disadvantage in the _current_ SL fonts. # I believe this is third time I raise this question on this list... > Changing our default font is a surprisingly large effort because of > truncation issues, but I think it could be worth it (though the > call isn't mine personally) - but we have to make a good font > decision (ideally both a sans and a sansmono). I konw it, because I'm using platform's font in the VWR-10131 patches, and the differences of the font metrics affect a lot of places of the viewer behaviour. But, Tofu, please remember that SL font has only Latin-1 coverage. Chinese, Japanese and Korean UI (among the current LL supported languages) use platform specific fallback fonts. I believe the right direction is changing the viewer code to handle various fonts so that any good font works with the viewer, as opposed to looking for a single set of (better) SL font and hard-code to that particular SL fonts. --- P.S., I'm have a problem rendering Arabic scripts on MacOS with my pango patch now. The reason is that Apple doesn't provides some critical information to pango called OpenType Layout Tables in their fonts. DejaVu, on the other hand, contains partial Arabic glyphs with OLT. It appeals to me... I'm uploading a new pango patch (VWR-10131) in this weekend, and Arabic-speaking Macintosh users can test it next week and can see what I'm saying. Arabic text using pango and Apple font is, ah, terrible. Arabic using pango and DejaVu is acceptable although not very good... Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From tofu.linden at lindenlab.com Thu Dec 11 16:10:56 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Dec 11 16:11:07 2008 Subject: [sldev] win32 libs zipfile on wiki seems rather empty... In-Reply-To: <1ds4ds6LnPdsGe5918Q8n.alissa_sabre@yahoo.co.jp> References: <4940A71A.5040306@gmail.com><49415A1C.7060000@lindenlab.com> <1ds4ds6LnPdsGe5918Q8n.alissa_sabre@yahoo.co.jp> Message-ID: <4941AC10.6060306@lindenlab.com> Alissa Sabre wrote: > I konw it, because I'm using platform's font in the VWR-10131 patches, > and the differences of the font metrics affect a lot of places of the > viewer behaviour. But, Tofu, please remember that SL font has only > Latin-1 coverage. Chinese, Japanese and Korean UI (among the current > LL supported languages) use platform specific fallback fonts. I > believe the right direction is changing the viewer code to handle > various fonts so that any good font works with the viewer, as opposed > to looking for a single set of (better) SL font and hard-code to that > particular SL fonts. I agree. This is a temporary solution to plug a conspicuous hole right now, as there is no ETA on a longer-term fix (finding and laying-out fonts is only part of the problem - our widget layout system is still based on fixed label sizes, so we can't exploit arbitrary fonts properly even if the font rendering system were completely superb; absolute predictability is still desirable, and that comes firstmost by bundling fonts). From bill.hoffman at kitware.com Fri Dec 12 10:05:17 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Dec 12 10:05:27 2008 Subject: [sldev] Kitware Power Outage Message-ID: <4942A7DD.2020608@kitware.com> Due to an ice storm Kitware is currently without power. The CVS repository and mailing list for CMake will be down until power is back. There is not a current estimate on when power will be resorted, however, we expect it to be back no later than Sunday night if not earlier. Sorry for any inconvenience, and I will keep you posted. -Bill From robertodevelop at gmail.com Sun Dec 14 16:15:04 2008 From: robertodevelop at gmail.com (Roberto Cezar Bianchini) Date: Sun Dec 14 16:15:07 2008 Subject: [sldev] [HELP] CMake with Visual Studio 2005 Message-ID: <496148810812141615o44b4b467r613ce40692f3bd93@mail.gmail.com> Hi list I've managed to compile the code with CMake and Visual Studio Express 2005. The things I want to do with the client would be more organized with a new project, then I've added a new project a to the solution. By the look of the existing ones, I included a Windows Forms App. (I hope this is the wright choice, but correct me if I'm wrong) I read the CMakeLists.txt and I tried to do the same with my own project, but when I tried to compile, the other existing projects gave me an error that my project didn't exist when I included the headers. Does anyone know what I'm missing here, or can anyone point me to a document to help me solve this problem? Thanks Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081214/98710c24/attachment.htm From poppy at lindenlab.com Mon Dec 15 12:26:58 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon Dec 15 12:28:16 2008 Subject: [sldev] [HELP] CMake with Visual Studio 2005 In-Reply-To: <496148810812141615o44b4b467r613ce40692f3bd93@mail.gmail.com> References: <496148810812141615o44b4b467r613ce40692f3bd93@mail.gmail.com> Message-ID: <4946BD92.3020207@lindenlab.com> Roberto Cezar Bianchini wrote: > Hi list > > I've managed to compile the code with CMake and Visual Studio Express > 2005. The things I want to do with the client would be more organized > with a new project, then I've added a new project a to the solution. By > the look of the existing ones, I included a Windows Forms App. (I hope > this is the wright choice, but correct me if I'm wrong) So you're creating the target with MSVS, or in (one of the) CMakeLists.txt? > I read the CMakeLists.txt and I tried to do the same with my own > project, but when I tried to compile, the other existing projects gave > me an error that my project didn't exist when I included the headers. > Does anyone know what I'm missing here, or can anyone point me to a > document to help me solve this problem? Thanks It depends on what you did. A link to a patch file would be very helpful; I can't understand what you tried to do by your description. + poppy From secondloop at gmail.com Tue Dec 16 00:09:58 2008 From: secondloop at gmail.com (azdel slade) Date: Tue Dec 16 00:10:01 2008 Subject: [sldev] stereoscopic patch Message-ID: <1e0ce1090812160009l3bee15e4y203a36fe8921745b@mail.gmail.com> Hi, Its probably not the cleanest patch, because I can't really code right now, but here's an svn diff of our stereoscopic code that we used for Becoming Dragon. More details and the patch are in the jira: https://jira.secondlife.com/browse/VWR-2972 Thanks to those developers who stopped by my performance after having seen it on the list. I hope this code is useful to the community. The windows stereo drivers are a nightmare, and were in my opinion the biggest hurdle to getting stereo working. If I could do it over, I'd have done it all in Linux. Thanks all, azdel From robin.cornelius at gmail.com Tue Dec 16 03:35:33 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Dec 16 03:35:35 2008 Subject: [sldev] Cryptographic signing of UDP packets Message-ID: Though this was worth kicking around here for a discussion. It was mentioned by Soft that adding a cryptographic hash/signature to each UDP packet was on the way, and given that the last 2 security updates were both UDP packet injection issues this could be a very good thing, but there may be unforced pitfalls and this is not in anyway aimed at LL, but its easy to balls up cryptography (And i for one is certainly not an expert in the field). The problems i see are 1) Increase of packet size and therefore bandwidth Is this going to be ALL UDP packets or just certain ones that are certainly more sensitive than others? Not applying to all still leaves a potential attack point but wastes bandwidth. This is also related to the size of the signature. If the signature is too small a brute force attack may be possible by just trying combinations of packets and getting a reply from the server, too large a signature and we have massive UDP packets so more bandwidth and lag? 2) Key exchange, I guess that this can occur over caps using https as part of the login, if we trust https for login then it should be trust worthy for key exchange? Also would this be some kind of direct symmetrical private key or would this be a public/private key asymmetrical system where essentially anyone could verify a packet if they can obtain a servers/clients public key. Keys could also be re-negotiated periodically to keep the actual keys in use rotating to make packet sniffing for brute force harder Any Thoughts? From secret.argent at gmail.com Tue Dec 16 05:34:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Dec 16 05:34:42 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: Message-ID: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> On 2008-12-16, at 05:35, Robin Cornelius wrote: > Is this going to be ALL UDP packets or just certain ones that are > certainly more sensitive than others? Not applying to all still leaves > a potential attack point but wastes bandwidth. This is also related to > the size of the signature. If the signature is too small a brute force > attack may be possible by just trying combinations of packets and > getting a reply from the server, too large a signature and we have > massive UDP packets so more bandwidth and lag? If you instead encrypt the UDP packets you won't need to add a signature to the packet itself, you can just encrypt the packet with a key passed through HTTPS CAPS at login. The computational overhead should be similar for encryption or signing at equivalent levels of security, and encryption would add privacy. Since you have a secure channel via HTTPS, you don't need to use a separate key exchange protocol, and you don't need the computational overhead of private keys. In fact just periodically exchanging a UUID over HTTPS to use in some fast short-period encryption technique would probably be enough. Don't serialize the packets, just keep updating the key. From tateru.nino at gmail.com Tue Dec 16 07:33:22 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Dec 16 07:33:35 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> Message-ID: <4947CA42.1030304@gmail.com> The current protocol would mean that you couldn't rely on any cipher block-chaining, mind. The packets can arrive out of order, and it is not critical if some are missed, as currently specified - but the overhead for a simple symmetrical cipher with a periodic key-exchange would be quite low. Argent Stonecutter wrote: > On 2008-12-16, at 05:35, Robin Cornelius wrote: >> Is this going to be ALL UDP packets or just certain ones that are >> certainly more sensitive than others? Not applying to all still leaves >> a potential attack point but wastes bandwidth. This is also related to >> the size of the signature. If the signature is too small a brute force >> attack may be possible by just trying combinations of packets and >> getting a reply from the server, too large a signature and we have >> massive UDP packets so more bandwidth and lag? > > If you instead encrypt the UDP packets you won't need to add a > signature to the packet itself, you can just encrypt the packet with a > key passed through HTTPS CAPS at login. The computational overhead > should be similar for encryption or signing at equivalent levels of > security, and encryption would add privacy. > > Since you have a secure channel via HTTPS, you don't need to use a > separate key exchange protocol, and you don't need the computational > overhead of private keys. > > In fact just periodically exchanging a UUID over HTTPS to use in some > fast short-period encryption technique would probably be enough. Don't > serialize the packets, just keep updating the key. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From robin.cornelius at gmail.com Tue Dec 16 07:51:38 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Dec 16 07:51:41 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <4947CA42.1030304@gmail.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> Message-ID: On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino wrote: > The current protocol would mean that you couldn't rely on any cipher > block-chaining, mind. The packets can arrive out of order, and it is not > critical if some are missed, as currently specified - but the overhead > for a simple symmetrical cipher with a periodic key-exchange would be > quite low. Yes of cause, each packet would have to be encrypted and decrypt-able with out any other packet dependencies due to the uncertain nature of UDP delivery. I quite like Argent's suggestion of encrypting the whole packet as this would not increase bandwidth as a signature would and you get small increase in privacy as a side effect, unable to sniff UDP packets without knowing the current key, so for debugging purposes you could still use SLproxy if it was able to cache the keys retrieved by caps and do the decode on the UDP and I guess for wider spread test systems eg OpenSims etc could could always rig a know decode key if you needed to sniff packets from multiple systems. Having some kind of assurance of the UDP packet source is also good for OGP/Hypergrid type situations as it makes sure the connection is authorized by at least what ever is providing the keys via caps. Robin From izzee at hotmail.co.uk Tue Dec 16 08:21:23 2008 From: izzee at hotmail.co.uk (izze euler) Date: Tue Dec 16 08:21:27 2008 Subject: [sldev] [HELP] What files to exclude/modify for a distributable SL client? Message-ID: Hi, I have made some alterations to the SL client source code and compiled using Visual C++ 2005 Express Edition. I have included the fmod files, which I now need to remove. How do I do this? Which files do I need to remove? And what changes do I need to make to the source code? Also, are there any other files which must be removed/excluded/replaced in order to distribute my version of the viewer and how will it affect the viewer? Again, what modifications need to be made to the source code? _________________________________________________________________ Are you a PC?? Upload your PC story and show the world http://clk.atdmt.com/UKM/go/122465942/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081216/0b73efb9/attachment.htm From infinity at lindenlab.com Tue Dec 16 09:36:18 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Tue Dec 16 09:36:31 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: Message-ID: <7E14328E-4CC6-4FD0-8A13-B1FF7AFE1F1B@lindenlab.com> fwiw... there is a protocol and an implementation to do a lot of this already... DTLS. and, it's implemented in recent versions of OpenSSL. but let's just say for a moment we go out and design our own crypto protocol. one would hope we (we being both LL and OpenSim folks) would look carefully at Flurher and McGrew's work with the RTP security profile over at the IETF. fwiw.. it is extremely unlikely that we're talking about a public key digital signature per packet. this would be prohibitively expensive in terms of CPU load. it is not, however, a problem for bandwidth. while most applications of digital signatures append/prepend a signature or authenticator to a packet (as is the case with the IPSec AH (Authentication Header)), if we wanted to do the crypto in the application layer, we could use the "signature with message recovery" construction (google 9796-4 for more info), though we would likely want to use something more like "message authentication code with message recovery" which i haven't seen in the wild. and honestly... one should be very careful about inventing new crypto. in other words... if we care about security, then we should attempt to look at well-worn solutions (like IPSec or DTLS.) if we've learned anything in the past two decades about applying crypto to problems, it's that it's extremely easy to build bad solutions. -cheers -m/? On Dec 16, 2008, at 3:35 AM, Robin Cornelius wrote: > Though this was worth kicking around here for a discussion. > > It was mentioned by Soft that adding a cryptographic hash/signature to > each UDP packet was on the way, and given that the last 2 security > updates were both UDP packet injection issues this could be a very > good thing, but there may be unforced pitfalls and this is not in > anyway aimed at LL, but its easy to balls up cryptography (And i for > one is certainly not an expert in the field). > > The problems i see are > > 1) Increase of packet size and therefore bandwidth > > Is this going to be ALL UDP packets or just certain ones that are > certainly more sensitive than others? Not applying to all still leaves > a potential attack point but wastes bandwidth. This is also related to > the size of the signature. If the signature is too small a brute force > attack may be possible by just trying combinations of packets and > getting a reply from the server, too large a signature and we have > massive UDP packets so more bandwidth and lag? > > 2) Key exchange, > > I guess that this can occur over caps using https as part of the > login, if we trust https for login then it should be trust worthy for > key exchange? > > Also would this be some kind of direct symmetrical private key or > would this be a public/private key asymmetrical system where > essentially anyone could verify a packet if they can obtain a > servers/clients public key. > > Keys could also be re-negotiated periodically to keep the actual keys > in use rotating to make packet sniffing for brute force harder > > > Any Thoughts? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tateru.nino at gmail.com Tue Dec 16 11:00:18 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Dec 16 11:00:30 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> Message-ID: <4947FAC2.1000108@gmail.com> Actually, the way the current protocol is written, if you could capture the packets off the wire, you could execute a known-plaintext attack and... Probably determine the key in a minimum of five minutes or so, assuming something like DES-56 and the sorts of usual data rates that we see in the current viewer. There are a couple ways I can think of to avoid that, but they require some slight tweaks to the format. Robin Cornelius wrote: > On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino wrote: > >> The current protocol would mean that you couldn't rely on any cipher >> block-chaining, mind. The packets can arrive out of order, and it is not >> critical if some are missed, as currently specified - but the overhead >> for a simple symmetrical cipher with a periodic key-exchange would be >> quite low. >> > > Yes of cause, each packet would have to be encrypted and decrypt-able > with out any other packet dependencies due to the uncertain nature of > UDP delivery. > > I quite like Argent's suggestion of encrypting the whole packet as > this would not increase bandwidth as a signature would and you get > small increase in privacy as a side effect, unable to sniff UDP > packets without knowing the current key, so for debugging purposes you > could still use SLproxy if it was able to cache the keys retrieved by > caps and do the decode on the UDP and I guess for wider spread test > systems eg OpenSims etc could could always rig a know decode key if > you needed to sniff packets from multiple systems. > > Having some kind of assurance of the UDP packet source is also good > for OGP/Hypergrid type situations as it makes sure the connection is > authorized by at least what ever is providing the keys via caps. > > Robin > > From zha.ewry at gmail.com Tue Dec 16 12:21:09 2008 From: zha.ewry at gmail.com (Zha Ewry) Date: Tue Dec 16 12:22:52 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <7E14328E-4CC6-4FD0-8A13-B1FF7AFE1F1B@lindenlab.com> References: <7E14328E-4CC6-4FD0-8A13-B1FF7AFE1F1B@lindenlab.com> Message-ID: <920d7d850812161221x27e3e2c4o414df7b450ae695c@mail.gmail.com> Actually I'd say the last 20 years of crypto history makes it very clear that its incredibly easy to write bad ones, hard to write good ones, and almost impossible to get *any* of them widely adopted. (Good, bad or ugly) ~ Zha On Tue, Dec 16, 2008 at 12:36 PM, Meadhbh Hamrick (Infinity) wrote: > fwiw... there is a protocol and an implementation to do a lot of this > already... DTLS. and, it's implemented in recent versions of OpenSSL. > > but let's just say for a moment we go out and design our own crypto > protocol. one would hope we (we being both LL and OpenSim folks) would look > carefully at Flurher and McGrew's work with the RTP security profile over at > the IETF. > > fwiw.. it is extremely unlikely that we're talking about a public key > digital signature per packet. this would be prohibitively expensive in terms > of CPU load. it is not, however, a problem for bandwidth. while most > applications of digital signatures append/prepend a signature or > authenticator to a packet (as is the case with the IPSec AH (Authentication > Header)), if we wanted to do the crypto in the application layer, we could > use the "signature with message recovery" construction (google 9796-4 for > more info), though we would likely want to use something more like "message > authentication code with message recovery" which i haven't seen in the wild. > and honestly... one should be very careful about inventing new crypto. > > in other words... if we care about security, then we should attempt to look > at well-worn solutions (like IPSec or DTLS.) if we've learned anything in > the past two decades about applying crypto to problems, it's that it's > extremely easy to build bad solutions. > > -cheers > -m/? > > On Dec 16, 2008, at 3:35 AM, Robin Cornelius wrote: > >> Though this was worth kicking around here for a discussion. >> >> It was mentioned by Soft that adding a cryptographic hash/signature to >> each UDP packet was on the way, and given that the last 2 security >> updates were both UDP packet injection issues this could be a very >> good thing, but there may be unforced pitfalls and this is not in >> anyway aimed at LL, but its easy to balls up cryptography (And i for >> one is certainly not an expert in the field). >> >> The problems i see are >> >> 1) Increase of packet size and therefore bandwidth >> >> Is this going to be ALL UDP packets or just certain ones that are >> certainly more sensitive than others? Not applying to all still leaves >> a potential attack point but wastes bandwidth. This is also related to >> the size of the signature. If the signature is too small a brute force >> attack may be possible by just trying combinations of packets and >> getting a reply from the server, too large a signature and we have >> massive UDP packets so more bandwidth and lag? >> >> 2) Key exchange, >> >> I guess that this can occur over caps using https as part of the >> login, if we trust https for login then it should be trust worthy for >> key exchange? >> >> Also would this be some kind of direct symmetrical private key or >> would this be a public/private key asymmetrical system where >> essentially anyone could verify a packet if they can obtain a >> servers/clients public key. >> >> Keys could also be re-negotiated periodically to keep the actual keys >> in use rotating to make packet sniffing for brute force harder >> >> >> Any Thoughts? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From robla at lindenlab.com Tue Dec 16 16:45:06 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Dec 16 16:45:08 2008 Subject: [sldev] RFP for build system improvements Message-ID: <49484B92.7030207@lindenlab.com> Hi folks, I just posted an RFP soliciting contractor bids to address our build system woes. The full RFP is available here: http://jira.secondlife.com/browse/VWR-11114 Direct link to the PDF: http://jira.secondlife.com/secure/attachment/20934/Build_Tool_RFP_2008-12-16.pdf Here's the intro: > This is a request for proposals to implement a series of small changes > to be made to our build configuration process, all of which will help > in reducing the number of steps needed to compile a viewer. A primary > goal is to make development on each supported platform as native and > streamlined as possible. Please keep this in mind as you prepare your > response and implement your solution. > > Developers currently have a difficult time building Second Life from > our provided source code. This affects hobbyists who might want to > fix bugs that annoy them, contract developers that we want deep > collaboration with, hardware makers we want to collaborate with > bugfixes on, and any other company or individual that wants to > innovate on the platform. > > Linden Lab is therefore soliciting proposals for organizations or > individuals that wish to address these issues under the auspices of a > paid contract. > Deadline for responses: January 11, 2008, 9am PST > Please address RFP responses via email to me. Thanks! Rob From lenglish5 at cox.net Tue Dec 16 18:21:47 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Dec 16 18:21:50 2008 Subject: [sldev] [AWG][OGP] generic client plugin/scripting API Message-ID: <4948623B.7060508@cox.net> all the various Second Life viewer developers are (and/or have been) talking about a plugin/scripting API. Here's a discussion in the Imprudence forum that describes a system that is coincidentally close to what I'd like to see made available in the pyogp viewer. http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=79&st=0&sk=t&sd=a I'd like to propose that we use the pyogp mailing list as one venue for discussing the design and implementation of such a beastie, with an eye to making it work, at least in principle, on any "compliant" Second Life viewer on any platform. It won't be easy to do this, but would allow a convergence of design in one direction, while allowing flexibility in others. Lawson English (Saijania Kuhn) From jhurliman at jhurliman.org Tue Dec 16 18:50:42 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Dec 16 18:50:46 2008 Subject: [sldev] [AWG][OGP] generic client plugin/scripting API In-Reply-To: <4948623B.7060508@cox.net> References: <4948623B.7060508@cox.net> Message-ID: If the proposal is for a plugin API for the *Second Life Viewer*, why would the discussion move off the *sldev* list and onto a list about a Python implementation of the Open Grid Protocol? If anything, this should be cross-posted to the realxtend mailing list. John On Tue, Dec 16, 2008 at 6:21 PM, Lawson English wrote: > all the various Second Life viewer developers are (and/or have been) > talking about a plugin/scripting API. Here's a discussion in the Imprudence > forum that describes a system that is coincidentally close to what I'd like > to see made available in the pyogp viewer. > > http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=79&st=0&sk=t&sd=a > > > > I'd like to propose that we use the pyogp mailing list as one venue for > discussing the design and implementation of such a beastie, with an eye to > making it work, at least in principle, on any "compliant" Second Life viewer > on any platform. It won't be easy to do this, but would allow a convergence > of design in one direction, while allowing flexibility in others. > > > Lawson English (Saijania Kuhn) > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081216/c3f27b4f/attachment.htm From jhurliman at jhurliman.org Tue Dec 16 18:57:09 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Dec 16 18:57:12 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: Message-ID: Side note: A private key is already exchanged at login, SecureSessionID. It's used for computing the AssetID of some new assets before they're uploaded by taking the MD5 of TransactionID+SecureSessionID on both the client and the server. This is the OpenMetaverse.UUID.Combine() function. John On Tue, Dec 16, 2008 at 3:35 AM, Robin Cornelius wrote: > Though this was worth kicking around here for a discussion. > > It was mentioned by Soft that adding a cryptographic hash/signature to > each UDP packet was on the way, and given that the last 2 security > updates were both UDP packet injection issues this could be a very > good thing, but there may be unforced pitfalls and this is not in > anyway aimed at LL, but its easy to balls up cryptography (And i for > one is certainly not an expert in the field). > > The problems i see are > > 1) Increase of packet size and therefore bandwidth > > Is this going to be ALL UDP packets or just certain ones that are > certainly more sensitive than others? Not applying to all still leaves > a potential attack point but wastes bandwidth. This is also related to > the size of the signature. If the signature is too small a brute force > attack may be possible by just trying combinations of packets and > getting a reply from the server, too large a signature and we have > massive UDP packets so more bandwidth and lag? > > 2) Key exchange, > > I guess that this can occur over caps using https as part of the > login, if we trust https for login then it should be trust worthy for > key exchange? > > Also would this be some kind of direct symmetrical private key or > would this be a public/private key asymmetrical system where > essentially anyone could verify a packet if they can obtain a > servers/clients public key. > > Keys could also be re-negotiated periodically to keep the actual keys > in use rotating to make packet sniffing for brute force harder > > > Any Thoughts? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081216/ada4e43f/attachment.htm From thomas.shikami at online.de Tue Dec 16 23:50:11 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Tue Dec 16 23:50:15 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> Message-ID: <4948AF33.60801@online.de> Robin Cornelius wrote: > On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino wrote: > >> The current protocol would mean that you couldn't rely on any cipher >> block-chaining, mind. The packets can arrive out of order, and it is not >> critical if some are missed, as currently specified - but the overhead >> for a simple symmetrical cipher with a periodic key-exchange would be >> quite low. ... > I quite like Argent's suggestion of encrypting the whole packet as > this would not increase bandwidth as a signature would and you get > small increase in privacy as a side effect, unable to sniff UDP > packets without knowing the current key, so for debugging purposes you > could still use SLproxy if it was able to cache the keys retrieved by > caps and do the decode on the UDP and I guess for wider spread test > systems eg OpenSims etc could could always rig a know decode key if > you needed to sniff packets from multiple systems. > Encrypting packets without signature is a common mistake done with cryptography, it still allows changing packets and it would go unnoticed as a signature is missing. A signature is mandatory for authenticating packets. If you are going to sign UDP packets, please don't create another home brewn crypto thing like those easy to crack simple MD5 sums over double-colon separated string, but instead use a real keyed hash. I recommend using HMAC-MD5 as it gives a 128bit signature and UDP packets and connections are short living anyways, so as finding collisions for MD5 still takes very long, it gives an average protection. To reduce the overhead, this hash may be reduced to 64bit and is still secure against quick injection. The hash key can be the secure session id and each packet could have a unixtime added as a nonce, so there would be a small time window in where packets are valid. This might give an overhead of like 96bit or 12 additional bytes. And most probably only packets involving modifying permissions, taking, deleting, L$ transfers, IMs and everything else low frequent can be armored by it. From tateru.nino at gmail.com Wed Dec 17 00:02:26 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Dec 17 00:02:41 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <4948AF33.60801@online.de> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> Message-ID: <4948B212.4040908@weblogsinc.com> Thomas Shikami wrote: > Robin Cornelius wrote: >> On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino >> wrote: >> >>> The current protocol would mean that you couldn't rely on any cipher >>> block-chaining, mind. The packets can arrive out of order, and it is >>> not >>> critical if some are missed, as currently specified - but the overhead >>> for a simple symmetrical cipher with a periodic key-exchange would be >>> quite low. > ... >> I quite like Argent's suggestion of encrypting the whole packet as >> this would not increase bandwidth as a signature would and you get >> small increase in privacy as a side effect, unable to sniff UDP >> packets without knowing the current key, so for debugging purposes you >> could still use SLproxy if it was able to cache the keys retrieved by >> caps and do the decode on the UDP and I guess for wider spread test >> systems eg OpenSims etc could could always rig a know decode key if >> you needed to sniff packets from multiple systems. >> > > Encrypting packets without signature is a common mistake done with > cryptography, it still allows changing packets and it would go > unnoticed as a signature is missing. A signature is mandatory for > authenticating packets. If you are going to sign UDP packets, please > don't create another home brewn crypto thing like those easy to crack > simple MD5 sums over double-colon separated string, but instead use a > real keyed hash. I recommend using HMAC-MD5 as it gives a 128bit > signature and UDP packets and connections are short living anyways, so > as finding collisions for MD5 still takes very long, it gives an > average protection. To reduce the overhead, this hash may be reduced > to 64bit and is still secure against quick injection. The hash key can > be the secure session id and each packet could have a unixtime added > as a nonce, so there would be a small time window in where packets are > valid. This might give an overhead of like 96bit or 12 additional > bytes. And most probably only packets involving modifying permissions, > taking, deleting, L$ transfers, IMs and everything else low frequent > can be armored by it. Wouldn't that have an extraordinarily high overhead computationally? We're potentially talking about thousands of packets per minute. Cycles spent generating and checking signatures can't be spent on anything else. The cycle cost of handling SL client-server communications is already fairly high. Is there a cheaper solution that fits the bill, or do only computationally intensive solutions clear the cryptographic bar? -- Tateru Nino http://www.massively.com/ From sllists at boroon.dasgupta.ch Wed Dec 17 01:53:54 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed Dec 17 01:53:57 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <4948AF33.60801@online.de> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> Message-ID: <4948CC32.2020107@boroon.dasgupta.ch> Thomas Shikami schrieb: > [...] And most probably only packets involving modifying permissions, > taking, deleting, L$ transfers, IMs and everything else low frequent > can be armored by it. If the sensitive stuff is low frequent (is that so?), wouldn't it make more sense to just move it to https? Boroondas From secret.argent at gmail.com Wed Dec 17 04:08:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 17 04:08:35 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <920d7d850812161221x27e3e2c4o414df7b450ae695c@mail.gmail.com> References: <7E14328E-4CC6-4FD0-8A13-B1FF7AFE1F1B@lindenlab.com> <920d7d850812161221x27e3e2c4o414df7b450ae695c@mail.gmail.com> Message-ID: <85C4D692-9CD8-4573-B87C-E6184FCA192A@gmail.com> On 2008-12-16, at 14:21, Zha Ewry wrote: > Actually I'd say the last 20 years of crypto history makes it very > clear that its > incredibly easy to write bad ones, hard to write good ones, and almost > impossible > to get *any* of them widely adopted. (Good, bad or ugly) I wouldn't suggest writing a new cryptosystem, but applying a known cryptosystem to an existing protocol isn't "writing a bad system". Use the existing SSL links for key exchange. From alissa_sabre at yahoo.co.jp Tue Dec 16 18:47:49 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Dec 17 04:45:44 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: Message-ID: > It was mentioned by Soft that adding a cryptographic hash/signature to > each UDP packet was on the way, and given that the last 2 security > updates were both UDP packet injection issues this could be a very > good thing, but there may be unforced pitfalls and this is not in > anyway aimed at LL, but its easy to balls up cryptography When I read this, several thoughts came into my mind. In short, what I want to say is: Why not IPsec? Why designing a new protocol? Reading discussion following the Robin's message made me believe that IPsec just fits. What SL requirement is not fulfilled by IPsec features? What is the problem of using IPsec? A great advantage of IPsec is that it is available on all SL-supported OS's. Another advantage of using IPsec is that we can get hardware acceleration. There are a lot of so-called enterprise-class Ethernet cards that can encipher/decipher IPsec datagram on the cards. Another example is VIA's low-cost CPUs that come with encryption-accelerator and their IPsec driver makes use of it. All of these things are possible that IPsec is an OS feature, and the hardware vendors can provide encryption drivers. I don't think they provides ones for SL viewer-specific API. Yet more. Authenticating a large number of small isolated data is technically difficult. Authentication of IP datagram just falls into this. IPsec people made a great effort to build a stable framework. I don't think LL engineers can do it better. And lastly, I remember that, in early days of SLDev list, Rob Linden repeatedly wrote "don't reinvent the wheel." I generally agree on the policy. (Although those days, he generally said so to deny opensource developers' idea...) Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From lenglish5 at cox.net Wed Dec 17 07:14:59 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Dec 17 07:15:02 2008 Subject: [sldev] [AWG][OGP] generic client plugin/scripting API In-Reply-To: References: <4948623B.7060508@cox.net> Message-ID: <49491773.903@cox.net> John Hurliman wrote: > If the proposal is for a plugin API for the *Second Life Viewer*, why > would the discussion move off the *sldev* list and onto a list about a > Python implementation of the Open Grid Protocol? If anything, this > should be cross-posted to the realxtend mailing list. > > John > Well, if you check the response to my suggestion on the imprudence forum, you'll note that I've already gotten folks there annoyed by suggesting that this might be a community-level task requiring a community-level response rather than application-specific. Pyogp is a apache v2 licensed project supported internally at least somewhat by Lindens, but completely open for all at all levels. Some of the other viewer projects are GPL, some are BSD. Pyogp is the most neutrally licensed amongst them, I think. It is also the most easily modified and least mature (therefore still nimble simply because its still an infant codebase). My proposal was to provide a neutral venue for discussion (well, from MY perspective) to avoid stepping on people's toes because I can see this moving very fast into "let's support THIS GUI/interface" instead of THAT one and MY viewer's capabilities are more important than yours. With pyogp, all interfaces would be equally supported because there currently are none. We can design our GUI/scripting/comand-file interface directly on top of the generic abstractions that would be applicable to all viewers. That way, none are favored, and if LL's implementation of the GUI changes for the GPL viewer at some point, those changes are safely abstracted away in the AppleEvents/AppleScript model of "user action" rather than GUI action. Likewise with whatever direction other viewer-writers which to pursue. The core abstractions stay the same, regardless of the GUI used for, e.g., "login." > On Tue, Dec 16, 2008 at 6:21 PM, Lawson English > wrote: > > all the various Second Life viewer developers are (and/or have > been) talking about a plugin/scripting API. Here's a discussion in > the Imprudence forum that describes a system that is > coincidentally close to what I'd like to see made available in the > pyogp viewer. > > http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=79&st=0&sk=t&sd=a > > > > > I'd like to propose that we use the pyogp mailing list as one > venue for discussing the design and implementation of such a > beastie, with an eye to making it work, at least in principle, on > any "compliant" Second Life viewer on any platform. It won't be > easy to do this, but would allow a convergence of design in one > direction, while allowing flexibility in others. > > > Lawson English (Saijania Kuhn) > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From carlo at alinoe.com Wed Dec 17 08:03:39 2008 From: carlo at alinoe.com (Carlo Wood) Date: Wed Dec 17 08:03:41 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> Message-ID: <20081217160339.GA8974@alinoe.com> On Tue, Dec 16, 2008 at 03:51:38PM +0000, Robin Cornelius wrote: > On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino wrote: > > The current protocol would mean that you couldn't rely on any cipher > > block-chaining, mind. The packets can arrive out of order, and it is not > > critical if some are missed, as currently specified - but the overhead > > for a simple symmetrical cipher with a periodic key-exchange would be > > quite low. > > Yes of cause, each packet would have to be encrypted and decrypt-able > with out any other packet dependencies due to the uncertain nature of > UDP delivery. But that would lead to low security. Strong encryption needs too much cpu, therefore the normal way to do this is using a single key which exchanged at the start of a session through a secure channel using public key encryption (very cpu intensive). However, if each packet has to be seperately decryptable, then the redundacy will be enormous and it would be very easy (cost little cpu) to obtain the key from from a number of packets (which assumes an attacker can intercept them), even so much that it isn't worthwhile to change the key every once in a while. What would be needed is an unencrypted sequence number of enough bits (say, 64) so that it can be used to seed a strong random number generator (together with a larger key determined at the start of the session). I don't know how large the current 'sequence number' field is, I assume 16 bit; then that would mean we'd need to add 64-16 = 48 bit to each packet. However, whatever the size currently is apparently we expect it to be enough to determine the order, and therefore the extra 48 bits are not needed and can be moved to the the salt. Thus: [16 bit sequence number][encrypted payload, without sequence number] Such a packet would have the same size as now. An other approach would be to assume that packets cannot be intercepted, only inserted. -- Carlo Wood From infinity at lindenlab.com Wed Dec 17 08:12:25 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Wed Dec 17 08:12:30 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <85C4D692-9CD8-4573-B87C-E6184FCA192A@gmail.com> References: <7E14328E-4CC6-4FD0-8A13-B1FF7AFE1F1B@lindenlab.com> <920d7d850812161221x27e3e2c4o414df7b450ae695c@mail.gmail.com> <85C4D692-9CD8-4573-B87C-E6184FCA192A@gmail.com> Message-ID: yes. yes it is. witness 802.11 WEP. they used RC4 in EXACTLY the wrong way. On Dec 17, 2008, at 4:08 AM, Argent Stonecutter wrote: > On 2008-12-16, at 14:21, Zha Ewry wrote: >> Actually I'd say the last 20 years of crypto history makes it very >> clear that its >> incredibly easy to write bad ones, hard to write good ones, and >> almost >> impossible >> to get *any* of them widely adopted. (Good, bad or ugly) > > I wouldn't suggest writing a new cryptosystem, but applying a known > cryptosystem to an existing protocol isn't "writing a bad system". > > Use the existing SSL links for key exchange. From monkowsk at watson.ibm.com Wed Dec 17 08:33:02 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Dec 17 08:33:11 2008 Subject: [sldev] [AWG][OGP] generic client plugin/scripting API In-Reply-To: <4948623B.7060508@cox.net> References: <4948623B.7060508@cox.net> Message-ID: <494929BE.6030707@watson.ibm.com> Gack! You lost me with the first word of your title: "generic." I believe that is a very naive approach. Unless you are specific about what kind of functionality you want to provide you will quickly get lost. Can I plug in a new render engine? Can I add a plugin that requires new message formats? Can I plug in mesh based objects? Can I add a plugin to create a local sim on my machine? As you say, people (many who are familiar with web page design, but have never looked at the viewer code) have been talking about the mystical plugin/scripting API forever. When you start with the word "generic" you're just encouraging chaos. Mike Lawson English wrote: > all the various Second Life viewer developers are (and/or have been) > talking about a plugin/scripting API. Here's a discussion in the > Imprudence forum that describes a system that is coincidentally close to > what I'd like to see made available in the pyogp viewer. ... From infinity at lindenlab.com Wed Dec 17 08:37:20 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Wed Dec 17 08:37:25 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <20081217160339.GA8974@alinoe.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <20081217160339.GA8974@alinoe.com> Message-ID: no. this is not how it would be done. take IPSec and SSL for instance. a single public key operation (two if you're also talking a encryption with authentication) is used to setup a symmetric session key. the symmetric key is then used for "bulk" encryption. encrypting with a symmetric cipher like AES is orders of magnitude less computationally intensive than an asymmetric cipher like RSA, Rabin-Williams or even ECC. strong PRNGs (Pseudo Random Number Generators) can themselves be CPU intensive as many times they are designed to be efficient for generating large numbers of bytes (10k-65k) and PRNG setup can be relatively computationally intensive. many modern CPUs include hardware support for bulk encryption/decryption, lowering the cost of bulk encryption even more. part of the problem with selecting a sequence number and seeding a PRNG with it is that it is relatively easy to guess the sequence number. there have in fact been a series of attacks based on this, including the recent DNS problems. and even if we could, there would still be the problem that applying a key stream to a packet. PRNGs are generally not intended to be used this way and are not designed to resist attacks based on key-stream recovery. again... a number of these issues were investigated (painfully) during the late 80's and 90's. the results are (D)TLS and IPSec. even better, there are existing 'vetted' implementations of each of these protocols. On Dec 17, 2008, at 8:03 AM, Carlo Wood wrote: > On Tue, Dec 16, 2008 at 03:51:38PM +0000, Robin Cornelius wrote: >> On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino >> wrote: >>> The current protocol would mean that you couldn't rely on any cipher >>> block-chaining, mind. The packets can arrive out of order, and it >>> is not >>> critical if some are missed, as currently specified - but the >>> overhead >>> for a simple symmetrical cipher with a periodic key-exchange would >>> be >>> quite low. >> >> Yes of cause, each packet would have to be encrypted and decrypt-able >> with out any other packet dependencies due to the uncertain nature of >> UDP delivery. > > But that would lead to low security. Strong encryption needs too much > cpu, therefore the normal way to do this is using a single key which > exchanged at the start of a session through a secure channel using > public key encryption (very cpu intensive). However, if each packet > has to be seperately decryptable, then the redundacy will be enormous > and it would be very easy (cost little cpu) to obtain the key from > from a number of packets (which assumes an attacker can intercept > them), even so much that it isn't worthwhile to change the key every > once in a while. > > What would be needed is an unencrypted sequence number of enough > bits (say, 64) so that it can be used to seed a strong random > number generator (together with a larger key determined at the > start of the session). > > I don't know how large the current 'sequence number' field is, > I assume 16 bit; then that would mean we'd need to add 64-16 = 48 bit > to each packet. However, whatever the size currently is apparently > we expect it to be enough to determine the order, and therefore > the extra 48 bits are not needed and can be moved to the the > salt. > > Thus: > > [16 bit sequence number][encrypted payload, without sequence number] > > Such a packet would have the same size as now. > > An other approach would be to assume that packets cannot > be intercepted, only inserted. > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From monkowsk at watson.ibm.com Wed Dec 17 08:54:49 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Dec 17 08:54:54 2008 Subject: [sldev] Avatar mesh/morph exporter/importer Message-ID: <49492ED9.1040604@watson.ibm.com> I've added a patch to http://jira.secondlife.com/browse/VWR-6199 that does not do all of what the issue asks for, but it does do some interesting things. 1. It provides a menu structure created by selecting "Meshes And Morphs..." from the Advanced->Character menu. 2. Its primary purpose is to allow machinimators to modify the Emote morphs (using a 3D graphics editor) to build more expressive avatars. 3. A secondary purpose is to allow residents to export their current appearance meshes to 3D graphics editors in order to map textures better. I'd also be interested to see if it's possible, using other tools, to then import the mesh as a sculpty to make a mannequin. The patch is applied to version 1.21.6 of the source code. Since I don't distribute a binary, I was hoping I could entice someone who does to incorporate this patch into their viewer. You can find more details at the link given above. Mike From dnbyena at gmail.com Wed Dec 17 09:27:20 2008 From: dnbyena at gmail.com (Khyota) Date: Wed Dec 17 09:27:24 2008 Subject: [sldev] Avatar mesh/morph exporter/importer In-Reply-To: <49492ED9.1040604@watson.ibm.com> References: <49492ED9.1040604@watson.ibm.com> Message-ID: <200812171227.20505.dnbyena@gmail.com> On Wednesday 17 December 2008 11:54:49 am Mike Monkowski wrote: > I've added a patch to http://jira.secondlife.com/browse/VWR-6199 that > does not do all of what the issue asks for, but it does do some > interesting things. > > 1. It provides a menu structure created by selecting "Meshes And > Morphs..." from the Advanced->Character menu. > 2. Its primary purpose is to allow machinimators to modify the Emote > morphs (using a 3D graphics editor) to build more expressive avatars. > 3. A secondary purpose is to allow residents to export their current > appearance meshes to 3D graphics editors in order to map textures > better. I'd also be interested to see if it's possible, using other > tools, to then import the mesh as a sculpty to make a mannequin. > > The patch is applied to version 1.21.6 of the source code. > > Since I don't distribute a binary, I was hoping I could entice someone > who does to incorporate this patch into their viewer. You can find more > details at the link given above. > > Mike > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges This sounds really exciting, This sounds really exciting, i applied the patch to trunk without error, but when i compiled i got this. In file included from /home/silver/trunk/indra/newview/llviewerjointmesh.h:37, from /home/silver/trunk/indra/newview/llvoavatar.h:46, from /home/silver/trunk/indra/newview/llcallingcard.cpp:62: /home/silver/trunk/indra/newview/llpolymesh.h:186: error: extra qualification ?L LPolyMesh::? on member ?getSharedMeshName? /home/silver/trunk/indra/newview/llpolymesh.h:330: error: extra qualification ?L LPolyMesh::? on member ?getMorphList? make[2]: *** [newview/CMakeFiles/secondlife-bin.dir/llcallingcard.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from /home/silver/trunk/indra/newview/llappviewer.cpp:100: /home/silver/trunk/indra/newview/llpolymesh.h:186: error: extra qualification ?L LPolyMesh::? on member ?getSharedMeshName? /home/silver/trunk/indra/newview/llpolymesh.h:330: error: extra qualification ?L LPolyMesh::? on member ?getMorphList? In file included from /home/silver/trunk/indra/newview/llviewerjointmesh.h:37, from /home/silver/trunk/indra/newview/llvoavatar.h:46, from /home/silver/trunk/indra/newview/llagent.cpp:121: /home/silver/trunk/indra/newview/llpolymesh.h:186: error: extra qualification ?L LPolyMesh::? on member ?getSharedMeshName? /home/silver/trunk/indra/newview/llpolymesh.h:330: error: extra qualification ?L LPolyMesh::? on member ?getMorphList? make[2]: *** [newview/CMakeFiles/secondlife-bin.dir/llagent.o] Error 1 make[2]: *** [newview/CMakeFiles/secondlife-bin.dir/llappviewer.o] Error 1 make[1]: *** [newview/CMakeFiles/secondlife-bin.dir/all] Error 2 make: *** [all] Error 2 Did i miss somethin? Khyota From lenglish5 at cox.net Wed Dec 17 09:48:38 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Dec 17 09:49:05 2008 Subject: [sldev] [AWG][OGP] generic client plugin/scripting API In-Reply-To: <494929BE.6030707@watson.ibm.com> References: <4948623B.7060508@cox.net> <494929BE.6030707@watson.ibm.com> Message-ID: <49493B76.2090103@cox.net> Mike Monkowski wrote: > Gack! You lost me with the first word of your title: "generic." I > believe that is a very naive approach. Unless you are specific about > what kind of functionality you want to provide you will quickly get > lost. Can I plug in a new render engine? Can I add a plugin that > requires new message formats? Can I plug in mesh based objects? Can > I add a plugin to create a local sim on my machine? > > As you say, people (many who are familiar with web page design, but > have never looked at the viewer code) have been talking about the > mystical plugin/scripting API forever. When you start with the word > "generic" you're just encouraging chaos. > > Mike > Well, that's the thing. Why can't it be generic, at least on some level? It's true that rendering plugins would be more difficult to make generic than, say, IRC plugins, but there are bound to be features applicable to any SL-compatible client, or you wouldn't be talking about a SL plugin. Right now, all the existing clients are either based directly on the GPL code or are reverse engineered to be compatible with the GPL code at the protocol level. What is wrong with trying to keep this compatibiltiy at the plugin level by abstracting away differences? That includes abstracting the existing GPL code as well since its the least extensible and flexible of all the viewers out there. L. > Lawson English wrote: >> all the various Second Life viewer developers are (and/or have been) >> talking about a plugin/scripting API. Here's a discussion in the >> Imprudence forum that describes a system that is coincidentally close >> to what I'd like to see made available in the pyogp viewer. ... > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From monkowsk at watson.ibm.com Wed Dec 17 10:13:22 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Dec 17 10:13:29 2008 Subject: [sldev] Avatar mesh/morph exporter/importer In-Reply-To: <200812171227.20505.dnbyena@gmail.com> References: <49492ED9.1040604@watson.ibm.com> <200812171227.20505.dnbyena@gmail.com> Message-ID: <49494142.3070005@watson.ibm.com> Khyota wrote: ... > /home/silver/trunk/indra/newview/llpolymesh.h:186: error: extra > qualification ?L LPolyMesh::? on > member ?getSharedMeshName? > /home/silver/trunk/indra/newview/llpolymesh.h:330: error: extra > qualification ?L LPolyMesh::? on > member ?getMorphList? ... > Did i miss somethin? No. Looks like I did. I guess my compiler is more forgiving. Just remove the "LLPolyMesh::" qualifiers. I'll post a fixed patch later today. Mike From monkowsk at watson.ibm.com Wed Dec 17 10:30:56 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Dec 17 10:31:06 2008 Subject: [sldev] [AWG][OGP] generic client plugin/scripting API In-Reply-To: <49493B76.2090103@cox.net> References: <4948623B.7060508@cox.net> <494929BE.6030707@watson.ibm.com> <49493B76.2090103@cox.net> Message-ID: <49494560.8010504@watson.ibm.com> Lawson English wrote: > Well, that's the thing. Why can't it be generic, at least on some level? > > It's true that rendering plugins would be more difficult to make generic > than, say, IRC plugins, but there are bound to be features applicable to > any SL-compatible client, or you wouldn't be talking about a SL plugin. > Right now, all the existing clients are either based directly on the GPL > code or are reverse engineered to be compatible with the GPL code at the > protocol level. What is wrong with trying to keep this compatibiltiy at > the plugin level by abstracting away differences? That includes > abstracting the existing GPL code as well since its the least extensible > and flexible of all the viewers out there. Because after you've abstracted away all of the differences, you have nothing left. There are no generic functions out there just waiting for an API. You seem to be talking about the message protocol. That is a very small part of the viewer. If all you want to do is intercept the message stream, perhaps you should say "generic plugin to the message protocol." I'm not sure that the word "generic" makes any difference there, but if you like it, go ahead. But if you believe that all the viewer does is process messages then you have a very different understanding of the viewer than I do. Yes, you can abstract it that way, but all of the work is in the details that are dismissed by that abstraction. Mike From robla at lindenlab.com Wed Dec 17 10:57:41 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Dec 17 10:57:47 2008 Subject: [sldev] Date correction (RFP for build system improvements) In-Reply-To: <49484B92.7030207@lindenlab.com> References: <49484B92.7030207@lindenlab.com> Message-ID: <49494BA5.1040509@lindenlab.com> Two important date corrections on this: * Due date is January 12 (Monday) instead of Sunday * Year is 2009. As much as I want to make the due date retroactive, I somehow doubt it would be effective. Rob On 12/16/2008 04:45 PM, Rob Lanphier wrote: > I just posted an RFP soliciting contractor bids to address our build > system woes. > > The full RFP is available here: > http://jira.secondlife.com/browse/VWR-11114 > > Direct link to the PDF: > http://jira.secondlife.com/secure/attachment/20934/Build_Tool_RFP_2008-12-16.pdf > > Here's the intro: > >> This is a request for proposals to implement a series of small changes >> to be made to our build configuration process, all of which will help >> in reducing the number of steps needed to compile a viewer. A primary >> goal is to make development on each supported platform as native and >> streamlined as possible. Please keep this in mind as you prepare your >> response and implement your solution. >> >> Developers currently have a difficult time building Second Life from >> our provided source code. This affects hobbyists who might want to >> fix bugs that annoy them, contract developers that we want deep >> collaboration with, hardware makers we want to collaborate with >> bugfixes on, and any other company or individual that wants to >> innovate on the platform. >> >> Linden Lab is therefore soliciting proposals for organizations or >> individuals that wish to address these issues under the auspices of a >> paid contract. >> Deadline for responses: January 11, 2008, 9am PST >> >> > > Please address RFP responses via email to me. > > > Thanks! > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From soft at lindenlab.com Wed Dec 17 16:24:47 2008 From: soft at lindenlab.com (Soft) Date: Wed Dec 17 16:24:50 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From thomas.shikami at online.de Thu Dec 18 00:49:31 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Thu Dec 18 00:49:28 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <4948AF33.60801@online.de> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> Message-ID: <494A0E9B.7060601@online.de> Thomas Shikami wrote: > Encrypting packets without signature is a common mistake done with > cryptography, it still allows changing packets and it would go > unnoticed as a signature is missing. A signature is mandatory for > authenticating packets. If you are going to sign UDP packets, please > don't create another home brewn crypto thing like those easy to crack > simple MD5 sums over double-colon separated string, but instead use a > real keyed hash. I recommend using HMAC-MD5 as it gives a 128bit > signature and UDP packets and connections are short living anyways, so > as finding collisions for MD5 still takes very long, it gives an > average protection. To reduce the overhead, this hash may be reduced > to 64bit and is still secure against quick injection. The hash key can > be the secure session id and each packet could have a unixtime added > as a nonce, so there would be a small time window in where packets are > valid. This might give an overhead of like 96bit or 12 additional > bytes. And most probably only packets involving modifying permissions, > taking, deleting, L$ transfers, IMs and everything else low frequent > can be armored by it. I just wanna add, this method has it's own flaws that I just noticed. By using a unixtime it's possible to salt collision attacks, but someone who's sniffing packets has the abilities to just replay for example a L$ or inventory transaction to get as many as he can do within the time window. To forge replay attacks a sequence number and a backlog window of sequence numbers seems mandatory to forge replay attacks. As a side effect, we'd get rid of double messages and other nuisances then. An additional note to encrypting packets, they add a package size penalty as well. As you'd need a cipher that is either driven in CBC mode or which is a stream cipher. Both need an initialization vector (IV) to initialize them for each packet, which adds an overhead of as much as the key size of most algorithms as well. So if you want AES-128 encryption of packets, you'd have an additional of 128bit for the IV alone and this isn't helping to stop replay attacks. You could also just guess what packet is for a L$ transaction (due to size of the packet) and change some bits with a guess. If you're lucky (only needs about 16bit or so changed) you can have any other arbitrary but high amount payed to you. This is another reason, that we need signatures for each packet and encryption alone isn't helping. For the reader who doesn't believe. There is enough on wikipedia already giving valid information about encryption and what all can go wrong. From thomas.shikami at online.de Thu Dec 18 00:51:39 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Thu Dec 18 00:51:31 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <20081217160339.GA8974@alinoe.com> Message-ID: <494A0F1B.907@online.de> Meadhbh Hamrick (Infinity) wrote: > part of the problem with selecting a sequence number and seeding a > PRNG with it is that it is relatively easy to guess the sequence > number. there have in fact been a series of attacks based on this, > including the recent DNS problems. and even if we could, there would > still be the problem that applying a key stream to a packet. PRNGs are > generally not intended to be used this way and are not designed to > resist attacks based on key-stream recovery. There is a PRNG in use that was designed for cryptography. It's implemented in the algorithm RC4 From robin.cornelius at gmail.com Thu Dec 18 01:14:15 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Dec 18 01:14:19 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <494A0E9B.7060601@online.de> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> Message-ID: On Thu, Dec 18, 2008 at 8:49 AM, Thomas Shikami wrote: > Thomas Shikami wrote: >> >> Encrypting packets without signature is a common mistake done with >> cryptography, it still allows changing packets and it would go unnoticed as >> a signature is missing. A signature is mandatory for authenticating packets. >> If you are going to sign UDP packets, please don't create another home brewn >> crypto thing like those easy to crack simple MD5 sums over double-colon >> separated string, but instead use a real keyed hash. I recommend using >> HMAC-MD5 as it gives a 128bit signature and UDP packets and connections are >> short living anyways, so as finding collisions for MD5 still takes very >> long, it gives an average protection. To reduce the overhead, this hash may >> be reduced to 64bit and is still secure against quick injection. The hash >> key can be the secure session id and each packet could have a unixtime added >> as a nonce, so there would be a small time window in where packets are >> valid. This might give an overhead of like 96bit or 12 additional bytes. And >> most probably only packets involving modifying permissions, taking, >> deleting, L$ transfers, IMs and everything else low frequent can be armored >> by it. > For low frequency and high risk packets such as pay or even an inventory transaction surely the answer must be put it on https caps, that immediately solves those issues then for those we can also use a reliable transport system TCP, although i believe those packets do use the "reliable" UDP handshake so that the viewer/serker ack's packets to confirm receipt and could resend if lost. > other arbitrary but high amount payed to you. This is another reason, that > we need signatures for each packet and encryption alone isn't helping. For > the reader who doesn't believe. There is enough on wikipedia already giving > valid information about encryption and what all can go wrong. Well the original goal of this, from what i understand, is authentication not encryption. Its the authentication that is most important here to ensure that a packet came from a given viewer or server and is not an injected or modified packet. Robin From secret.argent at gmail.com Thu Dec 18 01:32:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 18 01:32:46 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <494A0E9B.7060601@online.de> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> Message-ID: The proposed solutions are these: 1. add a signature to each packet. 2. encrypt each packet 3. transfer money-related packets over SSL 4. wrap the entire session in an IPSEC layer Of these, I think option 3 is most secure, most standards-compliant, and lowest overhead. It would also be likely to increase the reliability of money transactions at the cost of some increased latency. Since money transactions are not real-time events, and even many seconds of additional latency is acceptable, there's no reason not to use it. From tateru.nino at gmail.com Thu Dec 18 02:51:27 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Dec 18 02:51:41 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> Message-ID: <494A2B2F.9090002@weblogsinc.com> Argent Stonecutter wrote: > The proposed solutions are these: > > 1. add a signature to each packet. > 2. encrypt each packet > 3. transfer money-related packets over SSL > 4. wrap the entire session in an IPSEC layer > > Of these, I think option 3 is most secure, most standards-compliant, > and lowest overhead. It would also be likely to increase the > reliability of money transactions at the cost of some increased > latency. Since money transactions are not real-time events, and even > many seconds of additional latency is acceptable, there's no reason > not to use it. Option 3 also gives choices for stronger authentication. -- Tateru Nino http://www.massively.com/ From chaosstar at gmail.com Thu Dec 18 07:52:26 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Dec 18 07:52:29 2008 Subject: [sldev] [HELP] What files to exclude/modify for a distributable SL client? In-Reply-To: References: Message-ID: <9bb32d430812180752w1dd9cb03od7307930b3cfee6a@mail.gmail.com> Make sure not to ship llkdu.dll, the 'fonts' folder, the fmod files, and the vivox/voice dlls. In 1.22, fmod can be replaced with openAL, which is free to use and distribute, and the fonts (3 .ttf files) should in my opinion be replaced with open sourced/open commons versions. That would, in the end, leave llkdu.dll (which will hopefully sooner or later be obsoleted by an improved openJPEG lib), and vivox, which is probably bound to stay. On Tue, Dec 16, 2008 at 17:21, izze euler wrote: > Hi, > > I have made some alterations to the SL client source code and compiled using > Visual C++ 2005 Express Edition. I have included the fmod files, which I now > need to remove. How do I do this? Which files do I need to remove? And what > changes do I need to make to the source code? > > Also, are there any other files which must be removed/excluded/replaced in > order to distribute my version of the viewer and how will it affect the > viewer? Again, what modifications need to be made to the source code? > > > ________________________________ > Take your friends with you with Mobile Messenger. Click Here! > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From infinity at lindenlab.com Thu Dec 18 09:41:40 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Thu Dec 18 09:41:48 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <494A0F1B.907@online.de> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <20081217160339.GA8974@alinoe.com> <494A0F1B.907@online.de> Message-ID: RC4 is nearly completely broken. it is not to be used for new applications. On Dec 18, 2008, at 12:51 AM, Thomas Shikami wrote: > Meadhbh Hamrick (Infinity) wrote: >> part of the problem with selecting a sequence number and seeding a >> PRNG with it is that it is relatively easy to guess the sequence >> number. there have in fact been a series of attacks based on this, >> including the recent DNS problems. and even if we could, there >> would still be the problem that applying a key stream to a packet. >> PRNGs are generally not intended to be used this way and are not >> designed to resist attacks based on key-stream recovery. > > There is a PRNG in use that was designed for cryptography. It's > implemented in the algorithm RC4 > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From infinity at lindenlab.com Thu Dec 18 09:44:34 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Thu Dec 18 09:44:41 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> Message-ID: this is called "hyper-encryption" or "super-encryption" it is occasionally "bad" On Dec 18, 2008, at 1:32 AM, Argent Stonecutter wrote: > The proposed solutions are these: > > 1. add a signature to each packet. > 2. encrypt each packet > 3. transfer money-related packets over SSL > 4. wrap the entire session in an IPSEC layer > > Of these, I think option 3 is most secure, most standards-compliant, > and lowest overhead. It would also be likely to increase the > reliability of money transactions at the cost of some increased > latency. Since money transactions are not real-time events, and even > many seconds of additional latency is acceptable, there's no reason > not to use it. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From gcanaday at gmail.com Thu Dec 18 10:18:06 2008 From: gcanaday at gmail.com (Glen) Date: Thu Dec 18 10:18:46 2008 Subject: [sldev] projects list In-Reply-To: References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> Message-ID: <494A93DE.8090901@gmail.com> Hey all.. new to the sldev group. Been lurking for all of about 24 hrs. Is there a place with a list of ongoing viewer projects somewhere? For example: 1. Bubba McGreasy - OSS voice replacement 2. Jeeves Jones - new memory manager 3. Francois Freepy - multi-threaded renderer 4. Someone OnJira - OAL replacement for FMod ... etc.? -- GC From monkowsk at watson.ibm.com Thu Dec 18 11:01:52 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Dec 18 11:02:02 2008 Subject: [sldev] projects list In-Reply-To: <494A93DE.8090901@gmail.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> <494A93DE.8090901@gmail.com> Message-ID: <494A9E20.6030509@watson.ibm.com> Glen wrote: > Hey all.. new to the sldev group. Been lurking for all of about 24 hrs. > > Is there a place with a list of ongoing viewer projects somewhere? For > example: > > 1. Bubba McGreasy - OSS voice replacement > 2. Jeeves Jones - new memory manager > 3. Francois Freepy - multi-threaded renderer > 4. Someone OnJira - OAL replacement for FMod No. Anything in particular you're interested in? Are the ones above just examples or do you want to know about them specifically? Mike From gcanaday at gmail.com Thu Dec 18 11:18:47 2008 From: gcanaday at gmail.com (Glen) Date: Thu Dec 18 11:19:02 2008 Subject: [sldev] projects list In-Reply-To: <494A9E20.6030509@watson.ibm.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> <494A93DE.8090901@gmail.com> <494A9E20.6030509@watson.ibm.com> Message-ID: <494AA217.8010904@gmail.com> Just examples. I am interested in threading it, but that's a bigger job than someone unfamiliar with code base can dream of taking on. Dual (or quad) CPUs aren't much of a boon without actually using any concurrency. Essentially, I'm most interested in finding ways of squeezing performance out of it to match what the video card can actually do. I know it can be faster than 6fps on a 256MB ATI HD2600 with all enhancements turned off! I'm also interested in reducing / eliminating the dependence on licensed technology in the viewer, so if someone grabs the code they don't need to worry about something not working because a proprietary bit wasn't included in the source release. FMod / Vivox are two examples. Those are where I'd like to go, but as far as I'd get with any of it is really very much up in the air. I always have 50+ projects in the works. That's kind of why I was thinking of finding a clearing-house for people's ongoing viewer projects, so that if I found myself with the extra time to help out with something then I could pick & choose where I could do the most good. --GC Mike Monkowski wrote: > Glen wrote: >> Hey all.. new to the sldev group. Been lurking for all of about 24 hrs. >> >> Is there a place with a list of ongoing viewer projects somewhere? >> For example: >> >> 1. Bubba McGreasy - OSS voice replacement >> 2. Jeeves Jones - new memory manager >> 3. Francois Freepy - multi-threaded renderer >> 4. Someone OnJira - OAL replacement for FMod > > No. Anything in particular you're interested in? Are the ones above > just examples or do you want to know about them specifically? > > Mike > From monkowsk at watson.ibm.com Thu Dec 18 11:45:42 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Dec 18 11:45:53 2008 Subject: [sldev] projects list In-Reply-To: <494AA217.8010904@gmail.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> <494A93DE.8090901@gmail.com> <494A9E20.6030509@watson.ibm.com> <494AA217.8010904@gmail.com> Message-ID: <494AA866.2070804@watson.ibm.com> Glen wrote: > Just examples. I am interested in threading it, but that's a bigger job > than someone unfamiliar with code base can dream of taking on. Dual (or > quad) CPUs aren't much of a boon without actually using any concurrency. The viewer does use some helper threads. The rendering itself is confined to a single thread because OpenGL is difficult (if at all possible) to run multithreaded. > Essentially, I'm most interested in finding ways of squeezing > performance out of it to match what the video card can actually do. I > know it can be faster than 6fps on a 256MB ATI HD2600 with all > enhancements turned off! You can get an idea of which parts of the viewer are consuming the resources by running the Fast Timers (Advanced->Consoles->Fast Timers). That will let you decide where your efforts would be best applied. > I'm also interested in reducing / eliminating the dependence on licensed > technology in the viewer, so if someone grabs the code they don't need > to worry about something not working because a proprietary bit wasn't > included in the source release. FMod / Vivox are two examples. Linden is already pretty far along replacing Fmod with OpenAL thanks to some open source work http://jira.secondlife.com/browse/VWR-2662 Replacing Vivox is tough because Vivox hosts the voice servers. Of course, you could replace that as well. The good news, though, is that Vivox intends to open source some of their code, probably in 2009. > Those are where I'd like to go, but as far as I'd get with any of it is > really very much up in the air. I always have 50+ projects in the works. > That's kind of why I was thinking of finding a clearing-house for > people's ongoing viewer projects, so that if I found myself with the > extra time to help out with something then I could pick & choose where I > could do the most good. There are a few established alternate viewer groups (see http://wiki.secondlife.com/wiki/Alternate_viewers ). That would probably be your best bet for collaborative work. Mike From robla at lindenlab.com Thu Dec 18 12:07:13 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Dec 18 12:07:15 2008 Subject: [sldev] projects list In-Reply-To: <494AA217.8010904@gmail.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> <494A93DE.8090901@gmail.com> <494A9E20.6030509@watson.ibm.com> <494AA217.8010904@gmail.com> Message-ID: <494AAD71.7080907@lindenlab.com> On 12/18/2008 11:18 AM, Glen wrote: > That's kind of why I was thinking of finding a clearing-house for > people's ongoing viewer projects, so that if I found myself with the > extra time to help out with something then I could pick & choose where > I could do the most good. Here's the closest thing I can think of to a "project list", which is the list of patch bundles: http://jira.secondlife.com/browse/VWR-9010 We've moved toward a model where we try to cluster patches into areas of work. The best thing to do is to email this mailing list when you're ready to take on something, and/or hop onto IRC (irc.efnet.org #opensl) and ask, and/or show up at one of our weekly meetings to ask (2pm today in Hippotropolis). Rob From gcanaday at gmail.com Thu Dec 18 16:00:01 2008 From: gcanaday at gmail.com (Glen) Date: Thu Dec 18 16:00:06 2008 Subject: [sldev] http://jira.secondlife.com/browse/VWR-10607... can someone make a patch for me? Message-ID: <494AE401.3020008@gmail.com> Hey all, Can someone make up a patch for me? My skills with patch and diff are so rusty I can't remember them. This replaces lines 355-370 of llwindowsdl.cpp and should fix this: http://jira.secondlife.com/browse/VWR-10607. There are two changes. One is to add a check for "Video RAM:" as two words from the Xorg.?.log file, and the second is a very mild refactor to have it just open the file once, and not open and close it for each check. I can't get it compiled just yet (build system stuff.. cart before the horse? lol), but this one was ticking me off. >>>>>>>>>> 355 if (fp) { llinfos << "Looking in " << fname << " for VRAM info..." << llendl; rtn = x11_detect_VRAM_kb_fp(fp, ": VideoRAM: "); if (0 == rtn) { rtn = x11_detect_VRAM_kb_fp(fp, ": Memory: "); if (0 == rtn) { rtn = x11_detect_VRAM_kb_fp(fp, ": Video RAM: "); } } fclose(fp); } >>>>>>>>>>> 370 Also... what's the pastebin URL? I could just post it there I suppose... but I'd still hafta make a patch. --GC From gcanaday at gmail.com Thu Dec 18 16:02:42 2008 From: gcanaday at gmail.com (Glen) Date: Thu Dec 18 16:02:52 2008 Subject: [sldev] gtk Q Message-ID: <494AE4A2.2030202@gmail.com> Also, one question... what is gtk actually used for in the Linux version of the viewer? It seems a bit like overkill to use a big UI toolkit for something that draws all of its buttons in OGL. Is it for input handling, as I seem to remember reading something about in the archives? Or something else? --GC From tofu.linden at lindenlab.com Thu Dec 18 16:33:13 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Dec 18 16:33:13 2008 Subject: [sldev] gtk Q In-Reply-To: <494AE4A2.2030202@gmail.com> References: <494AE4A2.2030202@gmail.com> Message-ID: <494AEBC9.9010105@lindenlab.com> Right now, file dialogs, color-picker, warning dialogs, mozilla+gstreamer event queues, and copy-and-paste. Glen wrote: > Also, one question... what is gtk actually used for in the Linux version > of the viewer? It seems a bit like overkill to use a big UI toolkit for > something that draws all of its buttons in OGL. Is it for input > handling, as I seem to remember reading something about in the archives? > Or something else? > > --GC > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From dnbyena at gmail.com Thu Dec 18 16:34:21 2008 From: dnbyena at gmail.com (Cam Rapp) Date: Thu Dec 18 16:34:26 2008 Subject: [sldev] http://jira.secondlife.com/browse/VWR-10607... can someone make a patch for me? In-Reply-To: <494AE401.3020008@gmail.com> References: <494AE401.3020008@gmail.com> Message-ID: <200812181934.21724.dnbyena@gmail.com> ">>>>>>>>>> 355 ? ? if (fp) ? ? { ? ? ? ? llinfos << "Looking in " << fname ? ? ? ? ? ? << " for VRAM info..." << llendl; ? ? ? ? rtn = x11_detect_VRAM_kb_fp(fp, ": VideoRAM: "); ? ? ? ? if (0 == rtn) ? ? ? ? { ? ? ? ? ? ? rtn = x11_detect_VRAM_kb_fp(fp, ": Memory: "); ? ? ? ? ? ? if (0 == rtn) ? ? ? ? ? ? { ? ? ? ? ? ? ? ? rtn = x11_detect_VRAM_kb_fp(fp, ": Video RAM: "); ? ? ? ? ? ? } ? ? ? ? } ? ? ? ? fclose(fp); ? ? } ?>>>>>>>>>>> 370 Spacings gonna be quite messed up here, I work from svn trunk and created this patch with 'svn diff >> window.patch' from that directory. Thats how i normally do it, for a single file i mite have also done "svn diff indra/llwindow/llwindowsdl.cpp >> window.patch" for patching 'patch -p0 < window.patch' if it ever doesnt work i just do a find and replace to fix all the locations of the source files. 'patch -Rp0 < window.patch to unpatch it, and 'svn revert indra/llwindow/llwindow.cpp. if I ever end up distroying it and want to revert to the latest version. Khyota :) -------------- next part -------------- A non-text attachment was scrubbed... Name: window.patch Type: text/x-patch Size: 812 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081218/efd1679a/window.bin From gcanaday at gmail.com Thu Dec 18 16:48:07 2008 From: gcanaday at gmail.com (Glen) Date: Thu Dec 18 16:48:13 2008 Subject: [sldev] http://jira.secondlife.com/browse/VWR-10607... can someone make a patch for me? In-Reply-To: <200812181934.21724.dnbyena@gmail.com> References: <494AE401.3020008@gmail.com> <200812181934.21724.dnbyena@gmail.com> Message-ID: <494AEF47.9070108@gmail.com> thx a ton! i got it uploaded and attached to to the jira. --GC Cam Rapp wrote: > ">>>>>>>>>> 355 > if (fp) > { > llinfos << "Looking in " << fname > << " for VRAM info..." << llendl; > rtn = x11_detect_VRAM_kb_fp(fp, ": VideoRAM: "); > if (0 == rtn) > { > rtn = x11_detect_VRAM_kb_fp(fp, ": Memory: "); > if (0 == rtn) > { > rtn = x11_detect_VRAM_kb_fp(fp, ": Video RAM: "); > } > } > fclose(fp); > } > >>>>>>>>>>> 370 > > Spacings gonna be quite messed up here, > I work from svn trunk and created this patch with 'svn diff >> window.patch' > from that directory. Thats how i normally do it, for a single file i mite have > also done "svn diff indra/llwindow/llwindowsdl.cpp >> window.patch" > > for patching 'patch -p0 < window.patch' if it ever doesnt work i just do a > find and replace to fix all the locations of the source files. 'patch -Rp0 < > window.patch to unpatch it, and 'svn revert indra/llwindow/llwindow.cpp. if I > ever end up distroying it and want to revert to the latest version. > > Khyota :) > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From gcanaday at gmail.com Thu Dec 18 16:50:06 2008 From: gcanaday at gmail.com (Glen) Date: Thu Dec 18 16:50:13 2008 Subject: [sldev] gtk Q In-Reply-To: <494AEBC9.9010105@lindenlab.com> References: <494AE4A2.2030202@gmail.com> <494AEBC9.9010105@lindenlab.com> Message-ID: <494AEFBE.4090305@gmail.com> Ah, ok. the moz + gstreamer stuff would not be so simple to re-implement to remove the gtk dependency. I'll scratch that off my potential project list. Too big for me. --GC Tofu Linden wrote: > Right now, file dialogs, color-picker, warning dialogs, > mozilla+gstreamer event queues, and copy-and-paste. > > Glen wrote: > >> Also, one question... what is gtk actually used for in the Linux version >> of the viewer? It seems a bit like overkill to use a big UI toolkit for >> something that draws all of its buttons in OGL. Is it for input >> handling, as I seem to remember reading something about in the archives? >> Or something else? >> >> --GC >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > From robin.cornelius at gmail.com Fri Dec 19 02:33:15 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 19 02:33:17 2008 Subject: [sldev] gtk Q In-Reply-To: <494AEFBE.4090305@gmail.com> References: <494AE4A2.2030202@gmail.com> <494AEBC9.9010105@lindenlab.com> <494AEFBE.4090305@gmail.com> Message-ID: On Fri, Dec 19, 2008 at 12:50 AM, Glen wrote: > > Ah, ok. the moz + gstreamer stuff would not be so simple to re-implement to > remove the gtk dependency. I'll scratch that off my potential project list. > Too big for me. > Mozilla may end up solving itself if webkit or some other replacement for llmozlib's engine happens. And gstreamer should only be using Glib so the rest of Gtk could go just leaving the glib library. What was your proposal for changing the tool kit? It might still be worth pursuing? any reduced dependencies could be a good thing. Robin From secret.argent at gmail.com Fri Dec 19 06:22:31 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Dec 19 06:22:46 2008 Subject: [sldev] projects list In-Reply-To: <494AA866.2070804@watson.ibm.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <4948AF33.60801@online.de> <494A0E9B.7060601@online.de> <494A93DE.8090901@gmail.com> <494A9E20.6030509@watson.ibm.com> <494AA217.8010904@gmail.com> <494AA866.2070804@watson.ibm.com> Message-ID: <7867DA69-FCB8-4342-865B-3642138A4E99@gmail.com> On 2008-12-18, at 13:45, Mike Monkowski wrote: > Replacing Vivox is tough because Vivox hosts the voice servers. Of > course, you could replace that as well. The good news, though, is > that Vivox intends to open source some of their code, probably in > 2009. As mitigation, voice is not a critical functionality for Second Life. From robin.cornelius at gmail.com Fri Dec 19 07:39:28 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 19 07:39:30 2008 Subject: [sldev] [VWR] llkdu issues building the viewer under windows Message-ID: I'm seeing the following problem, the llkdu library is not downloading during the cmake configure, it is listed in install.xml and i have tried manually downloading and checking the md5sum and that is correct. If i manually download the library from S3 from:- http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/kdu-binaries-5.2.1-windows-20080617.tar.bz2 As listed in install.xml and install this for my viewer my viewer crashes at start up with a stack trace right through llkdu.dll. Now if take the llkdu from the last RC and use that, everything is fine. The file modification times are interesting :- >From latest RC 15-Oct-2008,00:41:14 684,032 bytes >From link from install.xml 13-June-2008 23:41:59 684,032 bytes From robin.cornelius at gmail.com Fri Dec 19 07:45:29 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 19 07:45:32 2008 Subject: [sldev] Re: [VWR] llkdu issues building the viewer under windows In-Reply-To: References: Message-ID: On Fri, Dec 19, 2008 at 3:39 PM, Robin Cornelius wrote: > I'm seeing the following problem, the llkdu library is not downloading > during the cmake configure, it is listed in install.xml and i have > tried manually downloading and checking the md5sum and that is > correct. If i manually download the library from S3 from:- > Sorry, i continue, stupid google mail There are two sections in install.xml, the first one "kdu" only lists pacakges under scp:// from a local linden server, the second section lists them as "kdu-binary" from S3. There is also a version number difference, 4.2.1 and 5.2.1 I guess there is something not quite right here. Thanks Robin From gcanaday at gmail.com Fri Dec 19 07:56:34 2008 From: gcanaday at gmail.com (Glen) Date: Fri Dec 19 07:57:07 2008 Subject: [sldev] gtk Q In-Reply-To: References: <494AE4A2.2030202@gmail.com> <494AEBC9.9010105@lindenlab.com> <494AEFBE.4090305@gmail.com> Message-ID: <494BC432.1090002@gmail.com> I know of no strictly OGL toolkits, so changing to one is kind of a lost cause ;P However, SL essentially has its own toolkit already written. All it really needs is a few widgets re-written, it seems. If I'm way off base then so be it; I'm not familiar enough with the viewer code to make that kind of judgment, nor am I familiar enough with gtk. Personally, I think if mozlib requires gtk, then SL requires gtk. Reinventing the wheel and writing a new SL-centric browsing engine to do the same thing is too huge. Maybe a webkit you're talking about would fix that. I really don't know. But gtk is GPLd like the viewer is - so it would be OK to port those widgets into SL's codebase and use SL's UI engine to draw them. Probably a huge job, and not one that is likely be very high on anyone's wish list. I'd originally looked at the build requirements and one of the things that makes it difficult for me - as a beginner with the viewer code - to compile my own is the fact that the dependencies are so heavy. So, removing the dependency on outside parts, i.e., gtk for one, would be a good thing. Lesson in contradiction, haha. Though, if it were to be done, would it be a welcome thing? And does the gecko engine require gtk by itself, or just this implementation of it? Millions of questions surrounding that. FYI - gstreamer works like absolute *crap* on my system. It's bad, really bad. Can't play video, period. Yes, all codecs and plug-ins are installed from the Ubuntu repositories. Yet, the SL viewer never does anything but crash when I attempt to play video media. Alternative back-ends are a Good Thing(tm). Xine seems to have no issues. It's not phonon doing it; it crashed when I was running a pure gtk-Gnome Ubuntu so I was hoping with phonon it would clear up, but no dice. The only common element is the presence of gstreamer and SL. Ripping out the gstreamer-only dependency for media would be absolutely fantastic for this reason, for me at least. So.. there goes glib and gtk, both, with the exception of the browser. I dunno. I'm rambling and thinking out loud with it. I do entirely believe that using a solely SL UI toolkit might solve (and prevent future recurrence of) a few issues such as VWR-10136, and once it's fully 64-bit un-screwed, one can make a 64-bit build without requiring 32-bit compatibility libraries. That should be a roadmap goal I think. I suppose what I'm actually getting at is that imo it would be easier to actually get into coding with the viewer if everything that doesn't have to be platform-specific, wasn't. I'm rambling and this is a book. Require mozlib, SDL, and OpenAL! Maybe I should write up a file chooser first. Color pickers are harder. --GC Robin Cornelius wrote: > On Fri, Dec 19, 2008 at 12:50 AM, Glen wrote: > >> Ah, ok. the moz + gstreamer stuff would not be so simple to re-implement to >> remove the gtk dependency. I'll scratch that off my potential project list. >> Too big for me. >> >> > > Mozilla may end up solving itself if webkit or some other replacement > for llmozlib's engine happens. And gstreamer should only be using Glib > so the rest of Gtk could go just leaving the glib library. > > What was your proposal for changing the tool kit? It might still be > worth pursuing? any reduced dependencies could be a good thing. > > Robin > > From lenglish5 at cox.net Fri Dec 19 08:40:04 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Dec 19 08:40:07 2008 Subject: [sldev] [ANNOUNCE]{AWG]{OGP] Enus Linden office hours today (Friday, 19 Dec 2008) discussing scripting API for pyogp Message-ID: <494BCE64.2080402@cox.net> Topic today at Enus Linden's office hours (9:30 AM SLT) will be a scripting/messaging API for pyogp and how that can serve as a model for a common scripting language for any SL compatible viewer (and how trying to develop one is bloody hard and exposes all sorts of hidden issues) http://slurl.com/secondlife/Longfellow/93/115/25 See you there. Lawson (Saijanai Kuhn) From lenglish5 at cox.net Fri Dec 19 11:19:42 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Dec 19 11:20:03 2008 Subject: [sldev] Re: [ANNOUNCE]{AWG]{OGP] Enus Linden office hours today (Friday, 19 Dec 2008) discussing scripting API for pyogp In-Reply-To: <494BCE64.2080402@cox.net> References: <494BCE64.2080402@cox.net> Message-ID: <494BF3CE.5050901@cox.net> https://wiki.secondlife.com/wiki/User:Enus_Linden/Office_Hours/2008_December_19 Lawson English wrote: > Topic today at Enus Linden's office hours (9:30 AM SLT) will be a > scripting/messaging API for pyogp and how that can serve as a model > for a common scripting language for any SL compatible viewer (and how > trying to develop one is bloody hard and exposes all sorts of hidden > issues) http://slurl.com/secondlife/Longfellow/93/115/25 > > See you there. > > Lawson (Saijanai Kuhn) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters > From soft at lindenlab.com Fri Dec 19 14:29:11 2008 From: soft at lindenlab.com (Soft) Date: Fri Dec 19 14:29:14 2008 Subject: [sldev] Re: [VWR] llkdu issues building the viewer under windows In-Reply-To: References: Message-ID: On Fri, Dec 19, 2008 at 9:45 AM, Robin Cornelius wrote: > On Fri, Dec 19, 2008 at 3:39 PM, Robin Cornelius > wrote: >> I'm seeing the following problem, the llkdu library is not downloading >> during the cmake configure, it is listed in install.xml and i have >> tried manually downloading and checking the md5sum and that is >> correct. If i manually download the library from S3 from:- >> > > Sorry, i continue, stupid google mail > > There are two sections in install.xml, the first one "kdu" only lists > pacakges under scp:// from a local linden server, the second section > lists them as "kdu-binary" from S3. > > There is also a version number difference, 4.2.1 and 5.2.1 > > I guess there is something not quite right here. The internal one would be for the actual kdu libs, not the llkdu wrapped libs. Internally, the version number changed to reflect what we're actually using, not because we actually upgraded at that point. What a mess. The public one should be changing any time the headers used to build it change, which would be fairly often. I'll see if I can get this one updated manually, and we'll revisit automating that guy. From dnbyena at gmail.com Fri Dec 19 20:56:34 2008 From: dnbyena at gmail.com (Khyota) Date: Fri Dec 19 20:57:02 2008 Subject: [sldev] Avatar mesh/morph exporter/importer Message-ID: <200812192356.35092.dnbyena@gmail.com> *Excitement* I was suprised that when i imported the base .obj of the upper body into blender, it ligned up EXACTLY with Domino Marama's imported mesh(after rotating 90 degrees). I made a simple change to it and exported it as .obj to reimport to SL, the mesh imported fine but was stuck in the 'base shape' the clothing and skin wouldnt bake correctly(see badbake screenshot and dont laugh at what i changed :)) Also the GTK window to save the OBJ's that appears uses the entire mesh directory as a default filename, whare normaly it is the only a filename. (see save1) I cant tell you how happy i am here Mike :) This will open up a lot of possibilities . -------------- next part -------------- A non-text attachment was scrubbed... Name: save1.png Type: image/png Size: 6728 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081219/aad04b2c/save1-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: badbake.png Type: image/png Size: 442026 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081219/aad04b2c/badbake-0001.png From alissa_sabre at yahoo.co.jp Sat Dec 20 02:49:13 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Dec 20 02:49:19 2008 Subject: What does GTK do in the Linux viewer (was: [sldev] gtk Q) In-Reply-To: <494BC432.1090002@gmail.com> References: <494BC432.1090002@gmail.com> Message-ID: <1s4vkw51JkPG5uc0t4rk8rk89.alissa_sabre@yahoo.co.jp> Glen: > what is gtk actually used for in the Linux version > of the viewer? Tofu: > Right now, file dialogs, color-picker, warning dialogs, > mozilla+gstreamer event queues, and copy-and-paste. Three things on the point. (1) Yes, there is a GTK-based color picker, but is is not usually used. The default behaviour in today's viewer is to use LLUI-based SL's own color picker. "Edit > Preferences > General > Use default system color picker" controls it. I guess you can simply disable the GTK-based color picker. (2) I believe clipbard operations are currently handled through Xlib and GTK is not used for the purpose. See VWR-7036. Note that the code that Tofu referred to as "The rewritten clipboard code by Alissa Sabre" in his comment on VWR-7036 *is* based on GTK... (3) The warning dialog (OSMessageBox) is currently based on GTK, and it is not straightforward to replace with LLUI, because OSMessageBox() may be called before OpenGL initialization (to notify some unexpected events, e.g., lack of some critical feature in the underlying OpenGL implementation...) > But gtk is GPLd like the viewer is - so it would be OK to port those > widgets into SL's codebase and use SL's UI engine to draw them. If you are planning to create your own viewer distribution, that's fine. However, I believe LL would never receive your patch if you put copies of GTK codes into the patch, because LL is selling the viewer source to third parties under no GPL terms, and _importing_ external GPL/LGPL codes into the viewer source will prevent LL from doing so. > Though, if it were to be done, would it be a welcome thing? Some people welcomes it, and some other doesn't. You are free to do so if you believe it is good. Nobody can stop you. That's the great feature of free software. Programming freedom. (Is RMS reading this? :-) My own opinion is just opposite. I've been trying to remove SDL dependency from the viewer code, replacing it with a GTK-based alternative. In other words, I'm _increasing_ GTK dependency. The original reason I started it is to improve the input method handling. Clipboard improvement is just a (good) side effect. See VWR-2261 for details on this issue. Alissa Sabre P.S., I recently restarted working on VWR-2261 (after 1/2 year blank), and I'm uploading a revised patch soon, hopefully within this weekend. -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From robin.cornelius at gmail.com Sat Dec 20 14:33:50 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Dec 20 14:34:03 2008 Subject: [sldev] [ANN] jira notify also available via IRC Message-ID: <494D72CE.8040709@gmail.com> Hey everyone, Following up to Rob's jira-notify email list announcement [1], I've added some features to my IRC bot that tracks in near real time jira-notify events. Also using the EFNet IRC network (the same one that we have #opensl on) I have a channel #opensl-jira which is displaying jira notify info so you can keep track in real time of new/updated/closed jira entries. As jira-notify is a high volume list this lets you not have an inbox full, and/or just monitor events when you are logged in, or just leave yourself idle in the channel and update when ever. I'm planning on also including the person who made the change that triggered the jira notify and possibly some other helpful features. But for those of you who are trying to keep jira in order or want to and can't deal with the volume of email it generates, this could be for you. We probably don't need to continue this discussion here so if you need anything else feel free to mail me direct or bring it up on #opensl Best regards Robin 1 https://lists.secondlife.com/pipermail/sldev/2007-November/006858.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081220/c005359c/signature.pgp From intertricity at gmail.com Sat Dec 20 16:02:09 2008 From: intertricity at gmail.com (intertricity@gmail.com) Date: Sat Dec 20 16:02:11 2008 Subject: [sldev] Plausibility of 16-bit sculpts? Message-ID: <001636163c5fe9b706045e83408f@google.com> Hey guys, so I've been thinking more and more about how nice it would be to not have wrinkling when I space two verts too close together. 1024 positions of precision is sounding -really- nice about now :) I was wondering if anyone has also been thinking about a 16-bit or higher implementation, and how to go about it? I'm not a coder, but as far as I know, JPEG2000 supports 16-bit depth, and as far as traffic concerns go, for a while, sculptors were using 128x128 and 256x256 image sizes- a 16-bit 64x64 shouldn't pose any difference in that perspective. Thoughts? Input? Ideas? Enlightenment? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081221/0a2bdc2a/attachment.htm From jpirkola at gmail.com Sun Dec 21 04:31:56 2008 From: jpirkola at gmail.com (Jani Pirkola) Date: Sun Dec 21 04:32:00 2008 Subject: [sldev] [META] News web site launched, SL Developers welcomed to join Message-ID: <6c9557390812210431m337521f2p85c8fe6be5bc243d@mail.gmail.com> Dear all, Since I left the realXtend program manager position due to family reasons, I founded a new web site for mostly technology related news from virtual worlds and virtual world platforms. As I have read the SL-dev mailing list for almost a year now, I know that many of you work with interesting projects of your own and I would like to give a change for everyone to have a news forum like this. As i understandably know most about realXtend, I started to write articles here: http://therexfiles.cybertechnews.com So that is the place for realXtend related news. Now I am discussing with OpenSim and Openlife + some other companies and communities if they would like to have their own subsection at the news site. If you have ideas, I welcome them and could make new subsections for specific purposes. All the news from subsections will be syndicated to the main news site at http://www.cybertechnews.com Please reply off-list to avoid cluttering SL-Dev, thanks! Best regards and Merry Christmas! Jani Pirkola -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081221/9141ac2f/attachment.htm From secret.argent at gmail.com Mon Dec 22 10:10:06 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Dec 22 10:10:10 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <20081217160339.GA8974@alinoe.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <20081217160339.GA8974@alinoe.com> Message-ID: <33FF1693-3E91-4270-8D10-A10582DAEB88@gmail.com> On 2008-12-17, at 10:03, Carlo Wood wrote: > However, if each packet > has to be seperately decryptable, then the redundacy will be enormous > and it would be very easy (cost little cpu) to obtain the key from > from a number of packets (which assumes an attacker can intercept > them), even so much that it isn't worthwhile to change the key every > once in a while. One thing to keep in mind is that this is probably not attempting to counter a MITM attack, it's meant to counter a forged packet attack involving a situation where the attacker knows the IP address of the user and of the server they're using in SL. > An other approach would be to assume that packets cannot > be intercepted, only inserted. Indeed. From monkowsk at watson.ibm.com Mon Dec 22 10:27:05 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Dec 22 10:27:11 2008 Subject: [sldev] Avatar mesh/morph exporter/importer In-Reply-To: <200812192356.35092.dnbyena@gmail.com> References: <200812192356.35092.dnbyena@gmail.com> Message-ID: <494FDBF9.4010104@watson.ibm.com> Khyota wrote: > *Excitement* I was suprised that when i imported the base .obj of the upper > body into blender, it ligned up EXACTLY with Domino Marama's imported > mesh(after rotating 90 degrees). I made a simple change to it and exported it > as .obj to reimport to SL, the mesh imported fine but was stuck in the 'base > shape' the clothing and skin wouldnt bake correctly(see badbake screenshot and > dont laugh at what i changed :)) Also the GTK window to save the OBJ's that > appears uses the entire mesh directory as a default filename, whare normaly it > is the only a filename. (see save1) > > I cant tell you how happy i am here Mike :) This will open up a lot of > possibilities . My guess with the texture baking is that the texture vertices changed. Compare the two .obj files to see. I intend to add support for the face information in the .obj file which ties the geometric vertices and normals to the texture vertices, but for now, they have to be a one to one correspondence in the correct order. You could try manually editing the .obj files to use the new geometric vertices with the old texture coordinates to see if that's the reason. I deliberately chose to give the file picker the full path name, since I thought it made sense to keep the .obj files with the .llm files. Is the problem that you want to put them somewhere else and you have to keep changing it for every save? Mike From cg at lindenlab.com Tue Dec 23 12:05:49 2008 From: cg at lindenlab.com (Christian Goetze (CG Linden)) Date: Tue Dec 23 12:05:59 2008 Subject: [sldev] Re: [VWR] llkdu issues building the viewer under windows In-Reply-To: References: Message-ID: <4951449D.5080206@lindenlab.com> Soft wrote: > On Fri, Dec 19, 2008 at 9:45 AM, Robin Cornelius > wrote: > >> On Fri, Dec 19, 2008 at 3:39 PM, Robin Cornelius >> wrote: >> >>> I'm seeing the following problem, the llkdu library is not downloading >>> during the cmake configure, it is listed in install.xml and i have >>> tried manually downloading and checking the md5sum and that is >>> correct. If i manually download the library from S3 from:- >>> >>> >> Sorry, i continue, stupid google mail >> >> There are two sections in install.xml, the first one "kdu" only lists >> pacakges under scp:// from a local linden server, the second section >> lists them as "kdu-binary" from S3. >> >> There is also a version number difference, 4.2.1 and 5.2.1 >> >> I guess there is something not quite right here. >> The latest open source drop for maint-viewer (1.22.0.106689) should have correct llkdu versions. Please check! -- cg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081223/882771e1/signature.pgp From gcanaday at gmail.com Tue Dec 23 12:22:46 2008 From: gcanaday at gmail.com (Glen) Date: Tue Dec 23 12:22:54 2008 Subject: [sldev] Re: What does GTK do in the Linux viewer In-Reply-To: <1s4vkw51JkPG5uc0t4rk8rk89.alissa_sabre@yahoo.co.jp> References: <494BC432.1090002@gmail.com> <1s4vkw51JkPG5uc0t4rk8rk89.alissa_sabre@yahoo.co.jp> Message-ID: <49514896.5070505@gmail.com> I prefer QT to GTK because I'm none too fond of obj-C. That's a religious thing, tho. Why not improve the input handling in SDL? And ahhh, I didn't know LL were taking the code elsewhere. No, I am not planning to nor do I have any wish to use anything other than the standard LL-coded viewer. Maintaining version compatibility with a moving target is a nightmare and I won't attempt it. I've done it before, and I have to say that I absolutely refuse to ever fork another large OSS project ever again ;P Patches against LL code yes, separate and soon to be incompatible code branch that is likely to undo bug fixes I code, no. Oh my, no. --GC Alissa Sabre wrote: > Glen: >> what is gtk actually used for in the Linux version >> of the viewer? > > Tofu: >> Right now, file dialogs, color-picker, warning dialogs, >> mozilla+gstreamer event queues, and copy-and-paste. > > Three things on the point. > > (1) Yes, there is a GTK-based color picker, but is is not usually > used. The default behaviour in today's viewer is to use LLUI-based > SL's own color picker. "Edit > Preferences > General > Use default > system color picker" controls it. I guess you can simply disable the > GTK-based color picker. > > (2) I believe clipbard operations are currently handled through Xlib > and GTK is not used for the purpose. See VWR-7036. Note that the > code that Tofu referred to as "The rewritten clipboard code by Alissa > Sabre" in his comment on VWR-7036 *is* based on GTK... > > (3) The warning dialog (OSMessageBox) is currently based on GTK, and > it is not straightforward to replace with LLUI, because OSMessageBox() > may be called before OpenGL initialization (to notify some unexpected > events, e.g., lack of some critical feature in the underlying OpenGL > implementation...) > >> But gtk is GPLd like the viewer is - so it would be OK to port those >> widgets into SL's codebase and use SL's UI engine to draw them. > > If you are planning to create your own viewer distribution, that's > fine. However, I believe LL would never receive your patch if you put > copies of GTK codes into the patch, because LL is selling the viewer > source to third parties under no GPL terms, and _importing_ external > GPL/LGPL codes into the viewer source will prevent LL from doing so. > >> Though, if it were to be done, would it be a welcome thing? > > Some people welcomes it, and some other doesn't. You are free to do > so if you believe it is good. Nobody can stop you. That's the great > feature of free software. Programming freedom. (Is RMS reading this? :-) > > My own opinion is just opposite. I've been trying to remove SDL > dependency from the viewer code, replacing it with a GTK-based > alternative. In other words, I'm _increasing_ GTK dependency. The > original reason I started it is to improve the input method handling. > Clipboard improvement is just a (good) side effect. See VWR-2261 for > details on this issue. > > Alissa Sabre > > P.S., I recently restarted working on VWR-2261 (after 1/2 year blank), > and I'm uploading a revised patch soon, hopefully within this weekend. > -------------------------------------- > Power up the Internet with Yahoo! Toolbar. > http://pr.mail.yahoo.co.jp/toolbar/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From gcanaday at gmail.com Tue Dec 23 12:25:50 2008 From: gcanaday at gmail.com (Glen) Date: Tue Dec 23 12:26:03 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <001636163c5fe9b706045e83408f@google.com> References: <001636163c5fe9b706045e83408f@google.com> Message-ID: <4951494E.6070600@gmail.com> Ouch. Best I can say. 6fps is bad bad bad. Sculpts help to break my viewer and bring it to its knees, 16-bit sculpts will hurt it even worse. Wait until the worst performance is around 15-20 fps on the worst hardware *then* consider it. --GC intertricity@gmail.com wrote: > Hey guys, so I've been thinking more and more about how nice it would be > to not have wrinkling when I space two verts too close together. 1024 > positions of precision is sounding -really- nice about now :) I was > wondering if anyone has also been thinking about a 16-bit or higher > implementation, and how to go about it? > > I'm not a coder, but as far as I know, JPEG2000 supports 16-bit depth, > and as far as traffic concerns go, for a while, sculptors were using > 128x128 and 256x256 image sizes- a 16-bit 64x64 shouldn't pose any > difference in that perspective. > > Thoughts? Input? Ideas? Enlightenment? :) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From gcanaday at gmail.com Tue Dec 23 12:30:31 2008 From: gcanaday at gmail.com (Glen) Date: Tue Dec 23 12:30:37 2008 Subject: [sldev] gtk Q In-Reply-To: References: <494AE4A2.2030202@gmail.com> <494AEBC9.9010105@lindenlab.com> <494AEFBE.4090305@gmail.com> <494BC432.1090002@gmail.com> Message-ID: <49514A67.5050600@gmail.com> Yes. But I was having fun typing a book about it; I could embed my reasoning for it that way. --GC Bj Raz wrote: > If I may try to summarize what you said Glen. It is to 'make Second Life > dependent upon its own libraries verses using gtk.' > > does that sum it up? > > BjRazzz Qinan > > On Fri, Dec 19, 2008 at 10:56 AM, Glen > wrote: > > I know of no strictly OGL toolkits, so changing to one is kind of a > lost cause ;P > > However, SL essentially has its own toolkit already written. All it > really needs is a few widgets re-written, it seems. If I'm way off > base then so be it; I'm not familiar enough with the viewer code to > make that kind of judgment, nor am I familiar enough with gtk. > Personally, I think if mozlib requires gtk, then SL requires gtk. > Reinventing the wheel and writing a new SL-centric browsing engine > to do the same thing is too huge. Maybe a webkit you're talking > about would fix that. I really don't know. > > But gtk is GPLd like the viewer is - so it would be OK to port those > widgets into SL's codebase and use SL's UI engine to draw them. > Probably a huge job, and not one that is likely be very high on > anyone's wish list. I'd originally looked at the build requirements > and one of the things that makes it difficult for me - as a beginner > with the viewer code - to compile my own is the fact that the > dependencies are so heavy. So, removing the dependency on outside > parts, i.e., gtk for one, would be a good thing. Lesson in > contradiction, haha. > > Though, if it were to be done, would it be a welcome thing? And does > the gecko engine require gtk by itself, or just this implementation > of it? Millions of questions surrounding that. > > FYI - gstreamer works like absolute *crap* on my system. It's bad, > really bad. Can't play video, period. Yes, all codecs and plug-ins > are installed from the Ubuntu repositories. Yet, the SL viewer never > does anything but crash when I attempt to play video media. > Alternative back-ends are a Good Thing(tm). Xine seems to have no > issues. It's not phonon doing it; it crashed when I was running a > pure gtk-Gnome Ubuntu so I was hoping with phonon it would clear up, > but no dice. The only common element is the presence of gstreamer > and SL. Ripping out the gstreamer-only dependency for media would be > absolutely fantastic for this reason, for me at least. So.. there > goes glib and gtk, both, with the exception of the browser. > > I dunno. I'm rambling and thinking out loud with it. I do entirely > believe that using a solely SL UI toolkit might solve (and prevent > future recurrence of) a few issues such as VWR-10136, and once it's > fully 64-bit un-screwed, one can make a 64-bit build without > requiring 32-bit compatibility libraries. That should be a roadmap > goal I think. I suppose what I'm actually getting at is that imo it > would be easier to actually get into coding with the viewer if > everything that doesn't have to be platform-specific, wasn't. I'm > rambling and this is a book. > > Require mozlib, SDL, and OpenAL! > > Maybe I should write up a file chooser first. Color pickers are harder. > > --GC > > > Robin Cornelius wrote: > > On Fri, Dec 19, 2008 at 12:50 AM, Glen > wrote: > > > Ah, ok. the moz + gstreamer stuff would not be so simple to > re-implement to > remove the gtk dependency. I'll scratch that off my > potential project list. > Too big for me. > > > > > Mozilla may end up solving itself if webkit or some other > replacement > for llmozlib's engine happens. And gstreamer should only be > using Glib > so the rest of Gtk could go just leaving the glib library. > > What was your proposal for changing the tool kit? It might still be > worth pursuing? any reduced dependencies could be a good thing. > > Robin > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > From carlo at alinoe.com Tue Dec 23 13:08:07 2008 From: carlo at alinoe.com (Carlo Wood) Date: Tue Dec 23 13:07:52 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <4951494E.6070600@gmail.com> References: <001636163c5fe9b706045e83408f@google.com> <4951494E.6070600@gmail.com> Message-ID: <20081223210807.GA5341@alinoe.com> On Tue, Dec 23, 2008 at 03:25:50PM -0500, Glen wrote: > Ouch. Best I can say. 6fps is bad bad bad. Sculpts help to break my > viewer and bring it to its knees, 16-bit sculpts will hurt it even > worse. Wait until the worst performance is around 15-20 fps on the worst > hardware *then* consider it. I had 3 fps with Linden Labs 32-bit client for linux. I then got the source code and compiled it for 64-bit, and got 30 fps, on the same hardware... -- Carlo Wood From markl at lindenlab.com Tue Dec 23 13:09:00 2008 From: markl at lindenlab.com (Mark Lentczner) Date: Tue Dec 23 13:09:02 2008 Subject: [sldev] [AWG][OGP] Planning Update Message-ID: Hey there AWG: We are super proud of what you all did this Summer. The OGP beta was a great, successful proof that an open grid can be built. As you may be aware, Linden Lab has been going through a top-to-bottom strategy review. We apologize that it?s taken Zero and our OGP team away from the AWG and kept it from making progress over the last four months. The good news is, we?re nearing the end of the process, and Linden Lab remains totally committed to an Internet-scale, open grid. We believe that that is the future of virtual worlds. For the next six weeks we?ll be working on our plan to move the OGP forward, and we?ll have it for you by the end of January. In the meantime, of course, we?d love to get your thoughts. Thank you all again for bearing with us. To me personally, OGP and open virtual worlds are the most powerful things that will happen to the Internet over the next five years. I know that we'll find the best way to make this come about, and I?m excited that we'll be designing the future together. Have a great winter holiday! I'll be on vacation most of the next two weeks, but I look forward to seeing you all at my office hours on January 6th, 2009. - Zero From gcanaday at gmail.com Tue Dec 23 13:24:46 2008 From: gcanaday at gmail.com (Glen) Date: Tue Dec 23 13:24:55 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <20081223210807.GA5341@alinoe.com> References: <001636163c5fe9b706045e83408f@google.com> <4951494E.6070600@gmail.com> <20081223210807.GA5341@alinoe.com> Message-ID: <4951571E.5030705@gmail.com> Then I'll be making that my next item, lol. 30+ is worth the effort! --GC Carlo Wood wrote: > On Tue, Dec 23, 2008 at 03:25:50PM -0500, Glen wrote: >> Ouch. Best I can say. 6fps is bad bad bad. Sculpts help to break my >> viewer and bring it to its knees, 16-bit sculpts will hurt it even >> worse. Wait until the worst performance is around 15-20 fps on the worst >> hardware *then* consider it. > > I had 3 fps with Linden Labs 32-bit client for linux. > I then got the source code and compiled it for 64-bit, > and got 30 fps, on the same hardware... > From tom at streamsense.net Tue Dec 23 13:32:22 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Dec 23 13:32:38 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <4951571E.5030705@gmail.com> References: <001636163c5fe9b706045e83408f@google.com> <4951494E.6070600@gmail.com> <20081223210807.GA5341@alinoe.com> <4951571E.5030705@gmail.com> Message-ID: <495158E6.7080805@streamsense.net> On Tue, Dec 23, 2008 at 03:25:50PM -0500, Glen wrote: >Ouch. Best I can say. 6fps is bad bad bad. Sculpts help to break my viewer and bring it to its knees, 16-bit sculpts will hurt it even worse. >Wait until the worst performance is around 15-20 fps on the worst hardware *then* consider it. Are you sure your viewer is affected by sculpts so significantly? Technically they're no more difficult to draw than a regular prim; except of course that they need to be recalculated several times as the sculpty map loads. ~T From dahliatrimble at gmail.com Tue Dec 23 13:37:17 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Dec 23 13:37:20 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <4951494E.6070600@gmail.com> References: <001636163c5fe9b706045e83408f@google.com> <4951494E.6070600@gmail.com> Message-ID: Wouldn't 16 bit textures be converted to the same floating point vertex data as the current 8 bit ones? I'm having a difficult time trying to understand why additional precision of the source texture would reduce frame rates. It seems all it would do is enable the artist to specify vertex position with a higher level of precision, it would not add more vertices or require a higher precision floating point number in the resulting sculpt mesh. Now it probably would slow down downloads of the textures somewhat. On Tue, Dec 23, 2008 at 12:25 PM, Glen wrote: > Ouch. Best I can say. 6fps is bad bad bad. Sculpts help to break my viewer > and bring it to its knees, 16-bit sculpts will hurt it even worse. Wait > until the worst performance is around 15-20 fps on the worst hardware *then* > consider it. > > --GC > > intertricity@gmail.com wrote: > >> Hey guys, so I've been thinking more and more about how nice it would be >> to not have wrinkling when I space two verts too close together. 1024 >> positions of precision is sounding -really- nice about now :) I was >> wondering if anyone has also been thinking about a 16-bit or higher >> implementation, and how to go about it? >> >> I'm not a coder, but as far as I know, JPEG2000 supports 16-bit depth, and >> as far as traffic concerns go, for a while, sculptors were using 128x128 and >> 256x256 image sizes- a 16-bit 64x64 shouldn't pose any difference in that >> perspective. >> >> Thoughts? Input? Ideas? Enlightenment? :) >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081223/50ac7618/attachment.htm From gcanaday at gmail.com Tue Dec 23 13:40:58 2008 From: gcanaday at gmail.com (Glen) Date: Tue Dec 23 13:41:04 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <495158E6.7080805@streamsense.net> References: <001636163c5fe9b706045e83408f@google.com> <4951494E.6070600@gmail.com> <20081223210807.GA5341@alinoe.com> <4951571E.5030705@gmail.com> <495158E6.7080805@streamsense.net> Message-ID: <49515AEA.6050907@gmail.com> Yep. Sculpts, textures (128x128 - 1024x1024), and avatars. Av imposters really doesn't help much at that point, nor does reducing every little extra thing to nothing. If compiling for a 64-bit native client will work better, awesome!! I'm gonna try it tonight :D I just hope things link properly and I can get all the shaders in there right. It's been a long, long time since I've tried. --GC Thomas Grimshaw wrote: > On Tue, Dec 23, 2008 at 03:25:50PM -0500, Glen wrote: > >Ouch. Best I can say. 6fps is bad bad bad. Sculpts help to break my > viewer and bring it to its knees, 16-bit sculpts will hurt it even > worse. >Wait until the worst performance is around 15-20 fps on the > worst hardware *then* consider it. > > Are you sure your viewer is affected by sculpts so significantly? > Technically they're no more difficult to draw than a regular prim; > except of course that they need to be recalculated several times as the > sculpty map loads. > > ~T > > > From dnbyena at gmail.com Tue Dec 23 14:09:31 2008 From: dnbyena at gmail.com (Khyota) Date: Tue Dec 23 14:09:36 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <49515AEA.6050907@gmail.com> References: <001636163c5fe9b706045e83408f@google.com> <495158E6.7080805@streamsense.net> <49515AEA.6050907@gmail.com> Message-ID: <200812231709.31774.dnbyena@gmail.com> >If compiling for a 64-bit native client will work better, awesome!! I'm >gonna try it tonight :D I just hope things link properly and I can get >all the shaders in there right. It's been a long, long time since I've >tried. Yus! it really does improve performance alot, as long as you do a Release not relwithdebinfo build which is secretly the default. The instructions for compiling have changed dramaticly though, If the wiki leaves you stranded you can always ask for help in #opensl irc on efnet. Weve been trying to clean up the wiki and and make sure the instructions work on all Linux distros. Khyota From dnbyena at gmail.com Tue Dec 23 15:50:03 2008 From: dnbyena at gmail.com (Khyota) Date: Tue Dec 23 15:50:11 2008 Subject: [sldev] Avatar mesh/morph exporter/importer In-Reply-To: <494FDBF9.4010104@watson.ibm.com> References: <200812192356.35092.dnbyena@gmail.com> <494FDBF9.4010104@watson.ibm.com> Message-ID: <200812231850.04707.dnbyena@gmail.com> >My guess with the texture baking is that the texture vertices changed. >Compare the two .obj files to see. I intend to add support for the face >information in the .obj file which ties the geometric vertices and >normals to the texture vertices, but for now, they have to be a one to >one correspondence in the correct order. You could try manually editing >the .obj files to use the new geometric vertices with the old texture >coordinates to see if that's the reason. A quick diff of the 2 files reveals that the ARE completely different, Quite new to modeling so im not sure how to keep them in the correct order. *wonders if anyone else is testing this with blender* Also importing the base mesh, seems to set it as the current mesh, instead of the base. Not sure if that was intended. I edited one of the vertex coordinates and it imported but i dont see a differance in the shape, but the texture baked correctly, ill play with that more later. >I deliberately chose to give the file picker the full path name, since I >thought it made sense to keep the .obj files with the .llm files. Is >the problem that you want to put them somewhere else and you have to >keep changing it for every save? Figured it would be the same as saving textures and snapshots :) not a big deal though. Khyota From robla at lindenlab.com Tue Dec 23 16:37:23 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Dec 23 16:37:25 2008 Subject: [sldev] Viewer security vulnerability disclosure group Message-ID: <49518443.7050107@lindenlab.com> Hi folks, When we had the vulnerability in the Second Life viewer back in October, we didn't have a great setup for communicating discreetly with people who are working on derived works to give them a warning that they'll need to publish an update to keep their users safe. Since the viewer is totally secure now, I suppose this isn't a problem, no? Hrmph, ok, I guess we should be a little more prepared next time. I did some fishing around for how other folks handle this. Here's info on Mozilla's Security Group, which seems most analogous. http://www.mozilla.org/projects/security/membership-policy.html And here's the "Announcing Security Vulnerabilities" section from Karl Fogel's book "Producing Open Source Software": http://producingoss.com/en/publicity.html#security Here's what I'd like from you all: 1. A discussion about what group of people it's going to be acceptable to provide early access to vulnerability information. For example, is it reasonable for us to require non-disclosure agreements of everyone in the group? I suspect that we'll need to take this step, but if there's a really good reason that I'm not thinking of why we shouldn't do this, I'd like to hear it. 2. If you're interested in being in this group, send me an email indicating your interest, and why you feel you should be in this group. With any luck, we'll have a group in place before we need have a vulnerability to disclose. Rob From robla at lindenlab.com Tue Dec 23 16:45:04 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Dec 23 16:45:06 2008 Subject: [sldev] Next Open Source meeting: Thursday, January 8 Message-ID: <49518610.9000000@lindenlab.com> Hi all, Since the next Open Source in-world meeting we would have falls on Christmas, and then the next one falls on New Years, that puts our next meeting that's not during a widely recognized holiday as January 8. Ignoring for a second that this happens to be Elvis Presley's birthday and a holiday in its own right, we're going to suck it up and have the meeting anyway. Many of us will probably be hanging out on IRC (irc.efnet.org #opensl - I'm llrobla) over the next couple of weeks, so if something comes up, this list and the IRC channel should be good spots. Happy holidays everyone! Rob From tom at streamsense.net Tue Dec 23 17:46:39 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Dec 23 17:46:56 2008 Subject: [sldev] Next Open Source meeting: Thursday, January 8 In-Reply-To: <49518610.9000000@lindenlab.com> References: <49518610.9000000@lindenlab.com> Message-ID: <4951947F.7020303@streamsense.net> Rob Lanphier wrote: > Ignoring for a second that this happens to be Elvis Presley's birthday > and a holiday in its own right I hate you From kakurady at gmail.com Tue Dec 23 17:52:30 2008 From: kakurady at gmail.com (=?UTF-8?B?5Y2h5bqT5ouJ6L+q?=) Date: Tue Dec 23 17:52:34 2008 Subject: [sldev] Re: What does GTK do in the Linux viewer In-Reply-To: <49514896.5070505@gmail.com> References: <494BC432.1090002@gmail.com> <1s4vkw51JkPG5uc0t4rk8rk89.alissa_sabre@yahoo.co.jp> <49514896.5070505@gmail.com> Message-ID: <21b2f1350812231752r4b07ae99k7bfd2fc88cda6d4e@mail.gmail.com> Object-C? We're not dealing with Mac OS here, GTK is based on plain C and GLib object system. And Qt needs a special pre-processor... Although my preference of GTK over Qt is also a religious thing (especially considering I've coded with neither) too. Geneko On Tue, Dec 23, 2008 at 3:22 PM, Glen wrote: > > I prefer QT to GTK because I'm none too fond of obj-C. That's a religious > thing, tho. > > Why not improve the input handling in SDL? > > And ahhh, I didn't know LL were taking the code elsewhere. No, I am not > planning to nor do I have any wish to use anything other than the standard > LL-coded viewer. Maintaining version compatibility with a moving target is a > nightmare and I won't attempt it. I've done it before, and I have to say > that I absolutely refuse to ever fork another large OSS project ever again > ;P Patches against LL code yes, separate and soon to be incompatible code > branch that is likely to undo bug fixes I code, no. Oh my, no. > > --GC > > Alissa Sabre wrote: > >> Glen: >> >>> what is gtk actually used for in the Linux version >>> of the viewer? >>> >> >> Tofu: >> >>> Right now, file dialogs, color-picker, warning dialogs, >>> mozilla+gstreamer event queues, and copy-and-paste. >>> >> >> Three things on the point. >> >> (1) Yes, there is a GTK-based color picker, but is is not usually >> used. The default behaviour in today's viewer is to use LLUI-based >> SL's own color picker. "Edit > Preferences > General > Use default >> system color picker" controls it. I guess you can simply disable the >> GTK-based color picker. >> >> (2) I believe clipbard operations are currently handled through Xlib >> and GTK is not used for the purpose. See VWR-7036. Note that the >> code that Tofu referred to as "The rewritten clipboard code by Alissa >> Sabre" in his comment on VWR-7036 *is* based on GTK... >> >> (3) The warning dialog (OSMessageBox) is currently based on GTK, and >> it is not straightforward to replace with LLUI, because OSMessageBox() >> may be called before OpenGL initialization (to notify some unexpected >> events, e.g., lack of some critical feature in the underlying OpenGL >> implementation...) >> >> But gtk is GPLd like the viewer is - so it would be OK to port those >>> widgets into SL's codebase and use SL's UI engine to draw them. >>> >> >> If you are planning to create your own viewer distribution, that's >> fine. However, I believe LL would never receive your patch if you put >> copies of GTK codes into the patch, because LL is selling the viewer >> source to third parties under no GPL terms, and _importing_ external >> GPL/LGPL codes into the viewer source will prevent LL from doing so. >> >> Though, if it were to be done, would it be a welcome thing? >>> >> >> Some people welcomes it, and some other doesn't. You are free to do >> so if you believe it is good. Nobody can stop you. That's the great >> feature of free software. Programming freedom. (Is RMS reading this? :-) >> >> My own opinion is just opposite. I've been trying to remove SDL >> dependency from the viewer code, replacing it with a GTK-based >> alternative. In other words, I'm _increasing_ GTK dependency. The >> original reason I started it is to improve the input method handling. >> Clipboard improvement is just a (good) side effect. See VWR-2261 for >> details on this issue. >> >> Alissa Sabre >> >> P.S., I recently restarted working on VWR-2261 (after 1/2 year blank), >> and I'm uploading a revised patch soon, hopefully within this weekend. >> -------------------------------------- >> Power up the Internet with Yahoo! Toolbar. >> http://pr.mail.yahoo.co.jp/toolbar/ >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081223/79402a6c/attachment-0001.htm From GordonWendt at gmail.com Tue Dec 23 19:34:28 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Dec 23 19:34:32 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49518443.7050107@lindenlab.com> References: <49518443.7050107@lindenlab.com> Message-ID: <493033a70812231934q770a7356oc22bc209883fe17a@mail.gmail.com> Rob to channel a little you know who here I think this idea stinks. If you have something to say you should be able to say it to all people on Sldev and not just to a select group of specially selected people so my suggestion on criteria is to have no criteria. Security isn't about being secretive about the problems with your software, security through obscurity DOES NOT WORK and just hurts trust in your software. The smart way to work is to allow people to report privately if they really want to but in general just be quick about dealing with fixing issues to minimize the window of opportunity. I'd also suggest that unless the person posts a JIRA issue in SEC or requests that it be moved there to stop blackholing issues. Blackholing issues is generally ineffective for several reasons 1) the main issue description usually has more than enough information to reproduce and for issues that weren't posted originally to SEC thanks to the email list of JIRA updates that is essentially public knowledge that you can't recall as soon as the issue is posted. 2) Even if one isn't true, any changes or comments giving more information or repro instructions become public knowledge per number one up to the point the issue is blackholed. 3) All that blackholing issues does is prevent resident input and residents from helping to repro, debug, and fix an issue and while that isn't always necessary I am sure that in many cases bugs could be fixed much better with user input. The above list may seem off topic since it mainly applys to your JIRA policy but it really applies to LL's whole view of security (and the opinion of most software makers) that residents can't help with security issues and that any resident input except from a very select group of contributors or distributors, made up in this case by patch/code submitters and third party viewer creators respectively, should be shunned. The take home summary of this is really that in my opinion it would be a huge mistake to create any sort of limited "first access" system for notification of security bugs. On Tue, Dec 23, 2008 at 7:37 PM, Rob Lanphier wrote: > Hi folks, > > When we had the vulnerability in the Second Life viewer back in October, > we didn't have a great setup for communicating discreetly with people > who are working on derived works to give them a warning that they'll > need to publish an update to keep their users safe. > > Since the viewer is totally secure now, I suppose this isn't a problem, > no? Hrmph, ok, I guess we should be a little more prepared next time. > > I did some fishing around for how other folks handle this. Here's info > on Mozilla's Security Group, which seems most analogous. > http://www.mozilla.org/projects/security/membership-policy.html > > And here's the "Announcing Security Vulnerabilities" section from Karl > Fogel's book "Producing Open Source Software": > http://producingoss.com/en/publicity.html#security > > Here's what I'd like from you all: > 1. A discussion about what group of people it's going to be acceptable > to provide early access to vulnerability information. For example, is > it reasonable for us to require non-disclosure agreements of everyone in > the group? I suspect that we'll need to take this step, but if there's > a really good reason that I'm not thinking of why we shouldn't do this, > I'd like to hear it. > 2. If you're interested in being in this group, send me an email > indicating your interest, and why you feel you should be in this group. > > With any luck, we'll have a group in place before we need have a > vulnerability to disclose. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081223/84a19af2/attachment.htm From soft at lindenlab.com Tue Dec 23 22:28:25 2008 From: soft at lindenlab.com (Soft) Date: Tue Dec 23 22:28:49 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <493033a70812231934q770a7356oc22bc209883fe17a@mail.gmail.com> References: <49518443.7050107@lindenlab.com> <493033a70812231934q770a7356oc22bc209883fe17a@mail.gmail.com> Message-ID: What we're talking about here is a couple days' lead time for viewer distributors and other key source consumers. This is very similar to how vulnerabilities in many services - and even the kernel - are handled with various *nix distros. This is different than "security through obscurity," which is generally used in reference to projects that try (and always fail) to rely on secrets in perpetuity. In evaluating the other points below - it's not clear what you mean about blackholing issues. Most security issues never exist in the public JIRA, either being discovered internally, or being reported to the security@ list. The minority of issues that do appear in pJIRA more often appear as SEC- issues. For the tiny remainder appearing in VWR- and SEC-, in the past we haven't really tried to mask the issues that should have gone to SEC- but didn't. I can only think of one issue that got moved into SEC- and it was less a security issue than a griefing issue. Do you have a specific issue or set of issues in mind? On Tue, Dec 23, 2008 at 9:34 PM, Gordon Wendt wrote: > Rob to channel a little you know who here I think this idea stinks. If you > have something to say you should be able to say it to all people on Sldev > and not just to a select group of specially selected people so my suggestion > on criteria is to have no criteria. Security isn't about being secretive > about the problems with your software, security through obscurity DOES NOT > WORK and just hurts trust in your software. > > The smart way to work is to allow people to report privately if they really > want to but in general just be quick about dealing with fixing issues to > minimize the window of opportunity. I'd also suggest that unless the person > posts a JIRA issue in SEC or requests that it be moved there to stop > blackholing issues. Blackholing issues is generally ineffective for several > reasons > > 1) the main issue description usually has more than enough information to > reproduce and for issues that weren't posted originally to SEC thanks to the > email list of JIRA updates that is essentially public knowledge that you > can't recall as soon as the issue is posted. > > 2) Even if one isn't true, any changes or comments giving more information > or repro instructions become public knowledge per number one up to the point > the issue is blackholed. > > 3) All that blackholing issues does is prevent resident input and residents > from helping to repro, debug, and fix an issue and while that isn't always > necessary I am sure that in many cases bugs could be fixed much better with > user input. > > The above list may seem off topic since it mainly applys to your JIRA policy > but it really applies to LL's whole view of security (and the opinion of > most software makers) that residents can't help with security issues and > that any resident input except from a very select group of contributors or > distributors, made up in this case by patch/code submitters and third party > viewer creators respectively, should be shunned. > > The take home summary of this is really that in my opinion it would be a > huge mistake to create any sort of limited "first access" system for > notification of security bugs. > > On Tue, Dec 23, 2008 at 7:37 PM, Rob Lanphier wrote: >> >> Hi folks, >> >> When we had the vulnerability in the Second Life viewer back in October, >> we didn't have a great setup for communicating discreetly with people >> who are working on derived works to give them a warning that they'll >> need to publish an update to keep their users safe. >> >> Since the viewer is totally secure now, I suppose this isn't a problem, >> no? Hrmph, ok, I guess we should be a little more prepared next time. >> >> I did some fishing around for how other folks handle this. Here's info >> on Mozilla's Security Group, which seems most analogous. >> http://www.mozilla.org/projects/security/membership-policy.html >> >> And here's the "Announcing Security Vulnerabilities" section from Karl >> Fogel's book "Producing Open Source Software": >> http://producingoss.com/en/publicity.html#security >> >> Here's what I'd like from you all: >> 1. A discussion about what group of people it's going to be acceptable >> to provide early access to vulnerability information. For example, is >> it reasonable for us to require non-disclosure agreements of everyone in >> the group? I suspect that we'll need to take this step, but if there's >> a really good reason that I'm not thinking of why we shouldn't do this, >> I'd like to hear it. >> 2. If you're interested in being in this group, send me an email >> indicating your interest, and why you feel you should be in this group. >> >> With any luck, we'll have a group in place before we need have a >> vulnerability to disclose. From soft at lindenlab.com Tue Dec 23 22:34:36 2008 From: soft at lindenlab.com (Soft) Date: Tue Dec 23 22:34:39 2008 Subject: [sldev] Next Open Source meeting: Thursday, January 8 In-Reply-To: <4951947F.7020303@streamsense.net> References: <49518610.9000000@lindenlab.com> <4951947F.7020303@streamsense.net> Message-ID: On Tue, Dec 23, 2008 at 7:46 PM, Thomas Grimshaw wrote: > Rob Lanphier wrote: >> >> Ignoring for a second that this happens to be Elvis Presley's birthday >> and a holiday in its own right > > I hate you Onhuh - thankyouveramuch *pose* From marinekelley at gmail.com Tue Dec 23 23:45:08 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Tue Dec 23 23:45:19 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49518443.7050107@lindenlab.com> References: <49518443.7050107@lindenlab.com> Message-ID: Hi Rob and everyone, Thank you for doing this effort for us, here are my personal thoughts on the subject : - Creating an early disclosure list is not only a good idea, it's vital for a project of this size and popularity. Some viewers are immensely popular and the users expect their tool of choice to be up to date with the latest security fixes. When a fix is deployed, you can be sure that the official maintainers and publishers of each viewer, and not only the creators, get swarmed with alerts, requests and even demands from the users. So they have to be ready for when the information is revealed. - We can't rely on security through obfuscation. Therefore, not alerting the end users when a flaw is discovered only gives an advantage to the people who are already exploiting it, and in most cases it is a matter of hours between the discovery and the massive exploit. - I think you can expect only premium accounts to sign a non disclosure agreement (to have grounds for a liability in case of a disclosure) but this is not too much of a problem : publishing a viewer and making it successful requires a lot of trust from the users, because they are putting their data and money in the hands of someone they don't know. This trust either comes from a good and widespread reputation (in my case) or an already settled partnership with Linden Lab (in Nicholaz' case for example). The former wouldn't really work for NPIs because people do not naturally trust them, the latter... well LL's trust would be somewhat already granted anyway. However if some of the well known viewer maintainers are on basic accounts, my apologies. This is merely my point of view and I have no statistics to back it up. Merry Xmas to you all Marine On 24 d?c. 08, at 01:37, Rob Lanphier wrote: > Hi folks, > > When we had the vulnerability in the Second Life viewer back in > October, > we didn't have a great setup for communicating discreetly with people > who are working on derived works to give them a warning that they'll > need to publish an update to keep their users safe. > > Since the viewer is totally secure now, I suppose this isn't a > problem, > no? Hrmph, ok, I guess we should be a little more prepared next time. > > I did some fishing around for how other folks handle this. Here's > info > on Mozilla's Security Group, which seems most analogous. > http://www.mozilla.org/projects/security/membership-policy.html > > And here's the "Announcing Security Vulnerabilities" section from > Karl > Fogel's book "Producing Open Source Software": > http://producingoss.com/en/publicity.html#security > > Here's what I'd like from you all: > 1. A discussion about what group of people it's going to be > acceptable > to provide early access to vulnerability information. For example, is > it reasonable for us to require non-disclosure agreements of > everyone in > the group? I suspect that we'll need to take this step, but if > there's > a really good reason that I'm not thinking of why we shouldn't do > this, > I'd like to hear it. > 2. If you're interested in being in this group, send me an email > indicating your interest, and why you feel you should be in this > group. > > With any luck, we'll have a group in place before we need have a > vulnerability to disclose. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From kerdezixe at gmail.com Wed Dec 24 00:01:43 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Dec 24 00:01:47 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <49518443.7050107@lindenlab.com> Message-ID: <8a1bfe660812240001g6c72a2dci2d329e723ff2e516@mail.gmail.com> On Wed, Dec 24, 2008 at 8:45 AM, Marine Kelley wrote: Hi !! > - Creating an early disclosure list is not only a good idea, it's vital for > a project of this size and popularity. Some viewers are immensely popular > and the users expect their tool of choice to be up to date with the latest > security fixes. When a fix is deployed, you can be sure that the official > maintainers and publishers of each viewer, and not only the creators, get > swarmed with alerts, requests and even demands from the users. So they have > to be ready for when the information is revealed. A limited early disclosure list is better than no disclosure at all. The only people that really need a full understanding (and disclosure) of the security hole are the developpers that can fix that hole. But, if there is a workaround to avoid/minimuze the effect of the security hole, then, it should be announced to everyone. > - We can't rely on security through obfuscation. Therefore, not alerting the > end users when a flaw is discovered only gives an advantage to the people > who are already exploiting it, and in most cases it is a matter of hours > between the discovery and the massive exploit. It's not security through obfuscation. a good exemple of security through obfuscation is the scrambling of texture cache. :) -- F4FQM Kerunix Flan Laurent Laborde From robin.cornelius at gmail.com Wed Dec 24 04:21:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Dec 24 04:21:27 2008 Subject: [sldev] [SVC][VWR] Broken inventory and ways to break it Message-ID: <49522941.4070307@gmail.com> Hey everyone, I've just spend some time analysing an account with a broken inventory and have discovered some interesting things. I believe I mentioned part of this at Robs office hours and Q said that the server should try to protect against these conditions (but the specific test case is new) Ways to break an inventory (easiest via libomv/libsl, but also my modifying the viewer, but i guess some horribleness could occur with corrupt or injected packets as well. 1. Buy the contents of an object and pass back a UUID zero as the target folder. This generates a usable toplevel folder next to My Inventory and Library. This can be undone by moving the folder back to the correct parent. This is actually quite useful. 2. Copy an inventory folder and set itself as its parent This really confuses the viewer and the viewer shows a new complete inventory root inside the new folder (All Texture/Trash/Lost and Found/Scripts etc folders present in new folder as well). Seems to break many inventory operations with the viewer 3. Create a folder with an ID the same as the inventory root Now how this happened was anybody guess, it was either by trying to remove a condition #2 by moving the folder back to the correct parent, or via some unknown mechanism. In any case this can happen and i have seen it and have an account in this state now, ps not mine, i didn't do it ;-) This causes failure in DragDrop cargo's where cargo==null, and triggers VWR-2003 when a drag drop (eg send inv item to profile) occurs. I probably should file some specific SVR issues for each of these conditions and generate repo code (on the beta grid i guess for saftey) but if any Linden wants a specific account that is in state #3 now i can provide one and a support ticket ID that a user has filed. Regards Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081224/9cec6f99/signature.pgp From tateru.nino at gmail.com Wed Dec 24 05:36:50 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Dec 24 05:37:12 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49518443.7050107@lindenlab.com> References: <49518443.7050107@lindenlab.com> Message-ID: <49523AF2.3030405@gmail.com> Such a list is certainly relatively common practice, and with good reasons. However, insofar as the NDAs go. No contract on earth will compel a party to do something that they don't intend to do in the first place. All an NDA does is basically give you the right to sue for damages in the event that someone leaks it. I don't think many people capable of *meeting* such damages are likely to be on the list. Essentially, it's a threat - albeit a polite one - and does not seem to serve Linden Lab's interest. Either you trust the people you're putting on the list, or you don't - and if you don't, don't add them to the list. NDAs aren't going to make the disclosures any more secure than without. If someone's going to leak the disclosures, they're going to do it anyway. The SL-Views NDAs hardly held much water -- they leaked like a sieve (I should know. Some of my private information was discussed at an SL-Views session and then leaked to a certain well-known blogger) Just my two bits, as a third-party (who has done this before). Rob Lanphier wrote: > Hi folks, > > When we had the vulnerability in the Second Life viewer back in October, > we didn't have a great setup for communicating discreetly with people > who are working on derived works to give them a warning that they'll > need to publish an update to keep their users safe. > > Since the viewer is totally secure now, I suppose this isn't a problem, > no? Hrmph, ok, I guess we should be a little more prepared next time. > > I did some fishing around for how other folks handle this. Here's info > on Mozilla's Security Group, which seems most analogous. > http://www.mozilla.org/projects/security/membership-policy.html > > And here's the "Announcing Security Vulnerabilities" section from Karl > Fogel's book "Producing Open Source Software": > http://producingoss.com/en/publicity.html#security > > Here's what I'd like from you all: > 1. A discussion about what group of people it's going to be acceptable > to provide early access to vulnerability information. For example, is > it reasonable for us to require non-disclosure agreements of everyone in > the group? I suspect that we'll need to take this step, but if there's > a really good reason that I'm not thinking of why we shouldn't do this, > I'd like to hear it. > 2. If you're interested in being in this group, send me an email > indicating your interest, and why you feel you should be in this group. > > With any luck, we'll have a group in place before we need have a > vulnerability to disclose. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From soft at lindenlab.com Wed Dec 24 05:58:00 2008 From: soft at lindenlab.com (Soft) Date: Wed Dec 24 05:58:03 2008 Subject: [sldev] [SVC][VWR] Broken inventory and ways to break it In-Reply-To: <49522941.4070307@gmail.com> References: <49522941.4070307@gmail.com> Message-ID: On Wed, Dec 24, 2008 at 6:21 AM, Robin Cornelius wrote: > > 3. Create a folder with an ID the same as the inventory root > > Now how this happened was anybody guess, it was either by trying to > remove a condition #2 by moving the folder back to the correct parent, > or via some unknown mechanism. In any case this can happen and i have > seen it and have an account in this state now, ps not mine, i didn't do > it ;-) Oof - the folder IDs aren't generated server-side? If it's possible to do this on the viewer end, that's a bit silly. > This causes failure in DragDrop cargo's where cargo==null, and triggers > VWR-2003 when a drag drop (eg send inv item to profile) occurs. Thanks, I saw you reopened that so we'll go ahead and dad protection there. > I probably should file some specific SVR issues for each of these > conditions and generate repo code (on the beta grid i guess for saftey) > but if any Linden wants a specific account that is in state #3 now i can > provide one and a support ticket ID that a user has filed. Please do create the JIRAs at least. Repro code would be awesome too. If the affected account hasn't been on aditi, getting them to log on there once would be helpful as well - then we can hijack and investigate the state of the inventory without disrupting agni activity. You rock as always :) From robin.cornelius at gmail.com Wed Dec 24 08:31:52 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Dec 24 08:31:59 2008 Subject: [sldev] [SVC][VWR] Broken inventory and ways to break it In-Reply-To: References: <49522941.4070307@gmail.com> Message-ID: <495263F8.2050105@gmail.com> Soft wrote: > Oof - the folder IDs aren't generated server-side? If it's possible to > do this on the viewer end, that's a bit silly. > Hi Soft, Well the server needs to just validate the requested target ID's to check that its not something stupid such as itsself, the inventory root, UUID.Zero or even something that just does not exist in the inventory, but i'm not sure how easy the last part is knowing nothing about the server architecture. > >> This causes failure in DragDrop cargo's where cargo==null, and triggers >> VWR-2003 when a drag drop (eg send inv item to profile) occurs. > > Thanks, I saw you reopened that so we'll go ahead and dad protection there. > Protection is good, but it could lead to unexplained "can't send items", something is seriously wrong if the cargo == NULL so may be an alert is appropriate. > >> I probably should file some specific SVR issues for each of these >> conditions and generate repo code (on the beta grid i guess for saftey) >> but if any Linden wants a specific account that is in state #3 now i can >> provide one and a support ticket ID that a user has filed. > > Please do create the JIRAs at least. Repro code would be awesome too. > If the affected account hasn't been on aditi, getting them to log on > there once would be helpful as well - then we can hijack and > investigate the state of the inventory without disrupting agni > activity. > Ok i've arranged for the user to login to beta and I will start to file individual JIRAs (SVC) as appropriate but with Christmas in the way and all it will take a little while. Is this also worth flagging to the inventory loss team, we have a situation where there is something in inventory i can only see via packet dumps, neither the viewer or libomv's InventoryManager are by default displaying this item so the item/folder appears to be lost. Regards and an appropriate Festive greeting to all. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081224/41ef3fb0/signature.pgp From gcanaday at gmail.com Wed Dec 24 09:58:36 2008 From: gcanaday at gmail.com (Glen) Date: Wed Dec 24 09:58:42 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: References: <001636163c5fe9b706045e83408f@google.com> <4951494E.6070600@gmail.com> Message-ID: <4952784C.4000502@gmail.com> I was thinking higher resolution. It's been a crazy week ;P --GC Dahlia Trimble wrote: > Wouldn't 16 bit textures be converted to the same floating point vertex > data as the current 8 bit ones? I'm having a difficult time trying to > understand why additional precision of the source texture would reduce > frame rates. It seems all it would do is enable the artist to specify > vertex position with a higher level of precision, it would not add more > vertices or require a higher precision floating point number in the > resulting sculpt mesh. > > Now it probably would slow down downloads of the textures somewhat. > > On Tue, Dec 23, 2008 at 12:25 PM, Glen > wrote: > > Ouch. Best I can say. 6fps is bad bad bad. Sculpts help to break my > viewer and bring it to its knees, 16-bit sculpts will hurt it even > worse. Wait until the worst performance is around 15-20 fps on the > worst hardware *then* consider it. > > --GC > > intertricity@gmail.com wrote: > > Hey guys, so I've been thinking more and more about how nice it > would be to not have wrinkling when I space two verts too close > together. 1024 positions of precision is sounding -really- nice > about now :) I was wondering if anyone has also been thinking > about a 16-bit or higher implementation, and how to go about it? > > I'm not a coder, but as far as I know, JPEG2000 supports 16-bit > depth, and as far as traffic concerns go, for a while, sculptors > were using 128x128 and 256x256 image sizes- a 16-bit 64x64 > shouldn't pose any difference in that perspective. > > Thoughts? Input? Ideas? Enlightenment? :) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From gcanaday at gmail.com Wed Dec 24 10:07:27 2008 From: gcanaday at gmail.com (Glen) Date: Wed Dec 24 10:07:33 2008 Subject: [sldev] Re: What does GTK do in the Linux viewer In-Reply-To: <21b2f1350812231752r4b07ae99k7bfd2fc88cda6d4e@mail.gmail.com> References: <494BC432.1090002@gmail.com> <1s4vkw51JkPG5uc0t4rk8rk89.alissa_sabre@yahoo.co.jp> <49514896.5070505@gmail.com> <21b2f1350812231752r4b07ae99k7bfd2fc88cda6d4e@mail.gmail.com> Message-ID: <49527A5F.3080303@gmail.com> true that. It's been a crazy week. and yes I was getting everything jumbled in my brain and mixed up with cocoa, which incidentally did not have any rum in it. Probably the problem... Though the special preprocessor makes cool stuff possible, like the signal / slots mechanism. I would never suggest that there be a qt port, no matter how cool it be. Simple requirements :D though right now it's NOT compiling >:[ gtk / gst issues. WHY it can't find it I have no idea. It's ridiculous. All of the requirements are installed. ???? wrote: > Object-C? We're not dealing with Mac OS here, GTK is based on plain C > and GLib object system. And Qt needs a special pre-processor... > > Although my preference of GTK over Qt is also a religious thing > (especially considering I've coded with neither) too. > > Geneko > > On Tue, Dec 23, 2008 at 3:22 PM, Glen > wrote: > > > I prefer QT to GTK because I'm none too fond of obj-C. That's a > religious thing, tho. > > Why not improve the input handling in SDL? > > And ahhh, I didn't know LL were taking the code elsewhere. No, I am > not planning to nor do I have any wish to use anything other than > the standard LL-coded viewer. Maintaining version compatibility with > a moving target is a nightmare and I won't attempt it. I've done it > before, and I have to say that I absolutely refuse to ever fork > another large OSS project ever again ;P Patches against LL code yes, > separate and soon to be incompatible code branch that is likely to > undo bug fixes I code, no. Oh my, no. > > --GC > > Alissa Sabre wrote: > > Glen: > > what is gtk actually used for in the Linux version > of the viewer? > > > Tofu: > > Right now, file dialogs, color-picker, warning dialogs, > mozilla+gstreamer event queues, and copy-and-paste. > > > Three things on the point. > > (1) Yes, there is a GTK-based color picker, but is is not usually > used. The default behaviour in today's viewer is to use LLUI-based > SL's own color picker. "Edit > Preferences > General > Use default > system color picker" controls it. I guess you can simply > disable the > GTK-based color picker. > > (2) I believe clipbard operations are currently handled through Xlib > and GTK is not used for the purpose. See VWR-7036. Note that the > code that Tofu referred to as "The rewritten clipboard code by > Alissa > Sabre" in his comment on VWR-7036 *is* based on GTK... > > (3) The warning dialog (OSMessageBox) is currently based on GTK, and > it is not straightforward to replace with LLUI, because > OSMessageBox() > may be called before OpenGL initialization (to notify some > unexpected > events, e.g., lack of some critical feature in the underlying OpenGL > implementation...) > > But gtk is GPLd like the viewer is - so it would be OK to > port those widgets into SL's codebase and use SL's UI engine > to draw them. > > > If you are planning to create your own viewer distribution, that's > fine. However, I believe LL would never receive your patch if > you put > copies of GTK codes into the patch, because LL is selling the viewer > source to third parties under no GPL terms, and _importing_ external > GPL/LGPL codes into the viewer source will prevent LL from doing so. > > Though, if it were to be done, would it be a welcome thing? > > > Some people welcomes it, and some other doesn't. You are free to do > so if you believe it is good. Nobody can stop you. That's the > great > feature of free software. Programming freedom. (Is RMS reading > this? :-) > > My own opinion is just opposite. I've been trying to remove SDL > dependency from the viewer code, replacing it with a GTK-based > alternative. In other words, I'm _increasing_ GTK dependency. The > original reason I started it is to improve the input method > handling. > Clipboard improvement is just a (good) side effect. See > VWR-2261 for > details on this issue. > > Alissa Sabre > > P.S., I recently restarted working on VWR-2261 (after 1/2 year > blank), > and I'm uploading a revised patch soon, hopefully within this > weekend. > -------------------------------------- > Power up the Internet with Yahoo! Toolbar. > http://pr.mail.yahoo.co.jp/toolbar/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > From gcanaday at gmail.com Wed Dec 24 10:19:19 2008 From: gcanaday at gmail.com (Glen) Date: Wed Dec 24 10:19:25 2008 Subject: [sldev] Plausibility of 16-bit sculpts? In-Reply-To: <200812231709.31774.dnbyena@gmail.com> References: <001636163c5fe9b706045e83408f@google.com> <495158E6.7080805@streamsense.net> <49515AEA.6050907@gmail.com> <200812231709.31774.dnbyena@gmail.com> Message-ID: <49527D27.2000407@gmail.com> Kinda aren't working on kubuntu 8.10. I'm on the irc channel now, cept no one appears alive. --GC Khyota wrote: >> If compiling for a 64-bit native client will work better, awesome!! I'm >> gonna try it tonight :D I just hope things link properly and I can get >> all the shaders in there right. It's been a long, long time since I've >> tried. > > Yus! it really does improve performance alot, as long as you do a Release not > relwithdebinfo build which is secretly the default. The instructions for > compiling have changed dramaticly though, If the wiki leaves you stranded you > can always ask for help in #opensl irc on efnet. Weve been trying to clean up > the wiki and and make sure the instructions work on all Linux distros. > > Khyota > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From phoenix at secondlife.com Wed Dec 24 10:48:00 2008 From: phoenix at secondlife.com (Phoenix) Date: Wed Dec 24 10:48:10 2008 Subject: [sldev] [SVC][VWR] Broken inventory and ways to break it In-Reply-To: <49522941.4070307@gmail.com> References: <49522941.4070307@gmail.com> Message-ID: On 2008-12-24, at 4:21 , Robin Cornelius wrote: > 1. Buy the contents of an object and pass back a UUID zero as the > target > folder. > > This generates a usable toplevel folder next to My Inventory and > Library. This can be undone by moving the folder back to the correct > parent. This is actually quite useful. In this state, the viewer should operate normally but many processes on the server assume a single 'root' folder. Inventory may break in strange and interesting ways that are hard for me to predict without some research. > 2. Copy an inventory folder and set itself as its parent > > This really confuses the viewer and the viewer shows a new complete > inventory root inside the new folder (All Texture/Trash/Lost and > Found/Scripts etc folders present in new folder as well). Seems to > break > many inventory operations with the viewer I'm surprised the viewer does not lock up building the internal indexes. That's good news. I'm not at all surprised that many operations break. > 3. Create a folder with an ID the same as the inventory root > > Now how this happened was anybody guess, it was either by trying to > remove a condition #2 by moving the folder back to the correct parent, > or via some unknown mechanism. In any case this can happen and i have > seen it and have an account in this state now, ps not mine, i didn't > do > it ;-) This should not be possible at all. Internally, inventory is uniquely identified as (agent_id, folder_id) for folders and (agent_id, item_id) for items. I would expect the duplicates to be suppressed and all evidence of their existence to disappear on relog. Please file service bugs and point me at them so I can take a look. Since all inventory use agent_id as part of their unique identification, it's not terribly important to generate the id on the server (thus requiring a major protocol overhaul). However, the back- end should loudly reject data inconsistencies such as these. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081224/f2b8f268/PGP.pgp From sldev at free.fr Wed Dec 24 11:02:46 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Dec 24 11:02:51 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49518443.7050107@lindenlab.com> References: <49518443.7050107@lindenlab.com> Message-ID: <20081224200246.706b05c4.sldev@free.fr> On Tue, 23 Dec 2008 16:37:23 -0800, Rob Lanphier wrote: > Hi folks, > > When we had the vulnerability in the Second Life viewer back in October, > we didn't have a great setup for communicating discreetly with people > who are working on derived works to give them a warning that they'll > need to publish an update to keep their users safe. > > Since the viewer is totally secure now, I suppose this isn't a problem, > no? Hrmph, ok, I guess we should be a little more prepared next time. Good idea, indeed... > .../... > Here's what I'd like from you all: > 1. A discussion about what group of people it's going to be acceptable > to provide early access to vulnerability information. Easy... Everyone listed in the "Alternate Viewers" section of the SL Wiki (https://wiki.secondlife.com/wiki/Alternate_viewers) should receive early warnings and security fixes. > For example, is it reasonable for us to require non-disclosure agreements > of everyone in the group? I suspect that we'll need to take this step, > but if there's a really good reason that I'm not thinking of why we > shouldn't do this, It's not reasonnable if it forces involved people to reveal their true (RL) identity and thus loose their anonimity... SL is very much an "adult game" for many of us, where many kinky stuff (such as BDSM) is roleplayed thanks to the (relative) anonimity Internet provides. Among the developpers involved in the alternate viewers developmenent and/or compilation/ distribution, I know at least 4 of them (me included) who certainly prefer to stay anonymous. Beside, as pointed out earlier in this thread, a non-disclosure agreement is hardly an efficient protection on Internet... It's easy to post 100% anonymously on a blog or forum. > I'd like to hear it. > 2. If you're interested in being in this group, send me an email > indicating your interest, and why you feel you should be in this group. As the developper of the Cool SL Viewer for Linux and its upstream for the Windoze and MacOS X versions (which are both based of the very same source code and patches I produce), I do feel I should be part of this group. Oh.... and Merry Christmas to everyone ! :-) Henri. From jacek.antonelli at gmail.com Wed Dec 24 14:13:18 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Wed Dec 24 14:13:20 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49518443.7050107@lindenlab.com> References: <49518443.7050107@lindenlab.com> Message-ID: <105c09f0812241413k4ba6f682lb989af81b37e52e2@mail.gmail.com> On Tue, Dec 23, 2008 at 6:37 PM, Rob Lanphier wrote: > For example, is > it reasonable for us to require non-disclosure agreements of everyone in > the group? I suspect that we'll need to take this step, but if there's > a really good reason that I'm not thinking of why we shouldn't do this, > I'd like to hear it. > 2. If you're interested in being in this group, send me an email > indicating your interest, and why you feel you should be in this group. I'd certainly be up for hearing about security vulnerabilities ahead of time, since it generally takes us a few days to prepare a new release. However, an NDA would be a total no-go. We have three different people involved in compiling and packaging our viewer (one for Linux, Mac, Windows each), and requiring volunteers to sign an NDA just to help us compile would be an unreasonable imposition. I _might_ be willing to sign an NDA myself so I could at least prepare the source ahead of time. But if the NDA restricted distribution of the fixed sourcecode, we wouldn't be able to make use of the head start anyway, since the other packagers wouldn't be allowed access to the updated source until after the vulnerability was made public. We could respond just as quickly, and without having to sign anything, by just waiting for the public announcement and source drop. - Jacek From nivardus at gmail.com Wed Dec 24 14:55:55 2008 From: nivardus at gmail.com (nivardus) Date: Wed Dec 24 14:55:58 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49518443.7050107@lindenlab.com> References: <49518443.7050107@lindenlab.com> Message-ID: <71d0a1670812241455u3e59ff25s99744d8e37ebbcee@mail.gmail.com> Vulnerability and exploit details are usually posted on blogs, found floating around on notecards, and otherwise get spread around long before they're reported --including the viewer->sim packet spoof vulnerability. Users should been warned the instant issues are confirmed. Make the security mailing list open admission or don't make one at all. Restricting awareness, especially of critical issues is counterproductive and superfluous. Gonta Maltz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081224/1ef9e2fd/attachment.htm From thomas.shikami at online.de Wed Dec 24 14:56:21 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed Dec 24 14:56:07 2008 Subject: [sldev] Cryptographic signing of UDP packets In-Reply-To: <33FF1693-3E91-4270-8D10-A10582DAEB88@gmail.com> References: <668A0D68-5DB7-4A44-8715-510CF96916AF@gmail.com> <4947CA42.1030304@gmail.com> <20081217160339.GA8974@alinoe.com> <33FF1693-3E91-4270-8D10-A10582DAEB88@gmail.com> Message-ID: <4952BE15.20008@online.de> Argent Stonecutter wrote: > On 2008-12-17, at 10:03, Carlo Wood wrote: >> An other approach would be to assume that packets cannot >> be intercepted, only inserted. > > Indeed. In that case, the SessionID in packets would be protection enough From GordonWendt at gmail.com Wed Dec 24 16:48:06 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Dec 24 16:48:10 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <71d0a1670812241455u3e59ff25s99744d8e37ebbcee@mail.gmail.com> References: <49518443.7050107@lindenlab.com> <71d0a1670812241455u3e59ff25s99744d8e37ebbcee@mail.gmail.com> Message-ID: <493033a70812241648l1a6a7913xfd4b6157f97d15b4@mail.gmail.com> Well put.Nivardus. To answer your Soft no I don't keep lists of issues that I have seen that since been removed and I in general do not look for issues however within the past few months I know of at least a few sim crash issues that were quietly moved to SEC from I think SVC. In principle I am also opposed to the entire concept of moving anything from an open to closed medium even if you can't do it fully retroactively for the reasons I went into before. On Wed, Dec 24, 2008 at 5:55 PM, nivardus wrote: > Vulnerability and exploit details are usually posted on blogs, found > floating around on notecards, and otherwise get spread around long before > they're reported --including the viewer->sim packet spoof vulnerability. > > Users should been warned the instant issues are confirmed. Make the > security mailing list open admission or don't make one at all. Restricting > awareness, especially of critical issues is counterproductive and > superfluous. > > Gonta Maltz > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081224/4b64fd55/attachment.htm From carlo at alinoe.com Wed Dec 24 17:48:50 2008 From: carlo at alinoe.com (Carlo Wood) Date: Wed Dec 24 17:48:33 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <493033a70812241648l1a6a7913xfd4b6157f97d15b4@mail.gmail.com> References: <49518443.7050107@lindenlab.com> <71d0a1670812241455u3e59ff25s99744d8e37ebbcee@mail.gmail.com> <493033a70812241648l1a6a7913xfd4b6157f97d15b4@mail.gmail.com> Message-ID: <20081225014850.GA25861@alinoe.com> On Wed, Dec 24, 2008 at 07:48:06PM -0500, Gordon Wendt wrote: > few months I know of at least a few sim crash issues that were quietly moved to > SEC from I think SVC. In principle I am also opposed to the entire concept of Sim crashing vulnerabilities are not being discussed however. That has nothing to do with viewer code, or the developers thereof. Carlo Wood From GordonWendt at gmail.com Wed Dec 24 19:32:11 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Dec 24 19:32:15 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <20081225014850.GA25861@alinoe.com> References: <49518443.7050107@lindenlab.com> <71d0a1670812241455u3e59ff25s99744d8e37ebbcee@mail.gmail.com> <493033a70812241648l1a6a7913xfd4b6157f97d15b4@mail.gmail.com> <20081225014850.GA25861@alinoe.com> Message-ID: <493033a70812241932h1e449c9bn940db423ba88fae8@mail.gmail.com> Carlo, read my previous post and Soft's response. Talking about the JIRA is slightly off-topic but as I stated in my first post it has to do with the overall way that security issues are handled which is relevant. On Wed, Dec 24, 2008 at 8:48 PM, Carlo Wood wrote: > On Wed, Dec 24, 2008 at 07:48:06PM -0500, Gordon Wendt wrote: > > few months I know of at least a few sim crash issues that were quietly > moved to > > SEC from I think SVC. In principle I am also opposed to the entire > concept of > > Sim crashing vulnerabilities are not being discussed however. > That has nothing to do with viewer code, or the developers thereof. > > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081224/2c182b4f/attachment.htm From samslists at gmail.com Wed Dec 24 21:05:10 2008 From: samslists at gmail.com (Sam's Lists) Date: Wed Dec 24 21:05:16 2008 Subject: [sldev] Getting started with eventlet and spawning... Message-ID: <558124520812242105g16b0bef8sb3e9989d29052cd3@mail.gmail.com> (Yes I am spending Christmas Eve on exactly this... :) So, I'm trying to set started porting an existing wsgi application I've written. The existing app uses Twisted and runs under CherryPy's wsgi server. I thought eventlet and spawning would be a nice replacement for twisted and cherrypy respectively. But I'm having trouble. The example from the docs for downloading three pages works fine. But when I try and embed the example as a wigi app I can't make it work. I've tried a bunch of variations, but here's the current one. #!/usr/bin/env python urls = ["http://www.google.com", "http://wiki.secondlife.com", "http://us.i1.yimg.com"] import time from eventlet import coros, httpc, util from webob import Request, Response def fetch(url): print "%s fetching %s" % (time.asctime(), url) x = httpc.get(url) print x print "%s fetched %s" % (time.asctime(), url) def FetchApp(environ, start_response): util.wrap_socket_with_coroutine_socket() pool = coros.CoroutinePool(max_size=4) waiters = [] for url in urls: waiters.append(pool.execute(fetch, url)) for waiter in waiters: waiter.wait() resp = Response("done") return resp(environ, start_response) Now when I run this as: % spawn test_eventlet.FetchApp and then I make a request with my web browser, I get the folowing output: (18686) **** Controller starting up at Thu Dec 25 04:52:16 2008 (18686) spawning 1 children with /usr/lib/python2.5/site-packages/ Spawning-0.8.7-py2.5.eg g/spawning/spawning_child.pyc (18686) serving wsgi with configuration: (18686) {'app': 'test_eventlet.FetchApp', (18686) 'app_factory': 'spawning.wsgi_factory.app_factory', (18686) 'args': ['test_eventlet.FetchApp'], (18686) 'deadman_timeout': 120, (18686) 'dev': True, (18686) 'host': '', (18686) 'middleware': [], (18686) 'num_processes': 1, (18686) 'port': 8080, (18686) 'processpool_workers': 0, (18686) 'source_directories': ['/home/sam/eventlet-fetcher'], (18686) 'threadpool_workers': 10, (18686) 'watch': None} (18687) reloader watching sys.modules (18687) using 10 threads (18687) wsgi starting up on http://0.0.0.0:8080/ Thu Dec 25 04:52:20 2008 fetching http://www.google.com Thu Dec 25 04:52:20 2008 fetching http://wiki.secondlife.com Thu Dec 25 04:52:20 2008 fetching http://us.i1.yimg.com Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/hubs/hub.py", li ne 294, in fire_timers timer() File "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/timer.py", line 77, in __call__ cb(*args, **kw) File "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/greenlib.py", line 314, in switch rval = other.switch(value, exc) error: cannot switch to a different thread Timer raised: Timer(0, , *(, [(2, 1, 6, '', ('64.233.161.99', 80)), (2, 1, 6, '', ('64.233.161.104', 80)), (2,1, 6, '', ('64.233.161.147', 80))]), **{}) Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/hubs/hub.py", line 294, in fire_timers timer() File "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/timer.py", line77, in __call__ cb(*args, **kw) File "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/greenlib.py", line 314, in switch rval = other.switch(value, exc) error: cannot switch to a different thread Timer raised: Timer(0, , *(, [(2, 1, 6, '', ('204.245.162.32', 80)), (2, 1, 6, '', ('204.245.162.27', 80))]), **{}) What at I doing wrong? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081224/451350bd/attachment-0001.htm From boy.lane at yahoo.com Thu Dec 25 01:07:14 2008 From: boy.lane at yahoo.com (Boy Lane) Date: Thu Dec 25 01:07:16 2008 Subject: [sldev] Viewer security vulnerability disclosure group Message-ID: <329370.24473.qm@web63808.mail.re1.yahoo.com> So who decides who is "good" or "bad" to receive or not to receive security bulletins? I think it's the wrong way to follow an Apple's approach to keep security issues secret until they possibly are fixed. I like the approach to openly disclose security gaps, make users aware of imminent risk, and try to fix issues ASAP with help of the users. That's how Microsoft handles it. Surely there are defenders of both camps. But SL is now opensource. I think the only way to properly handle security issues detected is to make everybody aware of them. Not to select a few deemed "white hats" to be informed but all people who work with the code. Be ensured the "black hats" do the same. One additional point @ Henri. You are registered with your RL details @ LL. As such I don't see a point with anonymity here. There is none. Merry Xmas! Boy http://my.opera.com/boylane From xuxiix at gmail.com Thu Dec 25 03:48:30 2008 From: xuxiix at gmail.com (Mikkel Hansen) Date: Thu Dec 25 03:48:33 2008 Subject: [sldev] [Compiling/Error] Error: the command 'make' exited with status 2 Message-ID: <2da30a0e0812250348i20f31450wdbc7037657933ff7@mail.gmail.com> Well, I'm relatively new to C++, compiling, mailinglists, etc... Anyway, when I try to compile the viewer I get an error. I'm on Linux Mint using cmake-SL to build the client. I've applied one patch ( https://jira.secondlife.com/browse/VWR-10001) to get past an error earlier, however, now I'm stuck again. D: I get the following error: ... [ 31%] Building CXX object llmessage/CMakeFiles/llmessage.dir/patch_dct.o [ 31%] Building CXX object llmessage/CMakeFiles/llmessage.dir/patch_idct.o Linking CXX static library libllmessage.a make[2]: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' [ 31%] Built target llmessage make[1]: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' make: *** [all] Error 2 make: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' Error: the command 'make' exited with status 2 I am not sure if you need the version name/whatever I am trying to compile, although if you do, I'll tell you. :p Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081225/e627b064/attachment.htm From sldev at free.fr Thu Dec 25 07:08:40 2008 From: sldev at free.fr (Henri Beauchamp) Date: Thu Dec 25 07:08:45 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <329370.24473.qm@web63808.mail.re1.yahoo.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> Message-ID: <20081225160840.30c2ee2a.sldev@free.fr> On Thu, 25 Dec 2008 01:07:14 -0800 (PST), Boy Lane wrote: > One additional point @ Henri. You are registered with > your RL details @ LL. > As such I don't see a point with anonymity here. There > is none. Nope... All what LL got and needs is an email address (also used for Paypal money exchanges) and my IP when I connect to the grid. They don't have anything else. You will also notice that, like would be epxected in most UE contries and to comply with their privacy laws, LL is not even requesting a RL name any more in their resident registration forms. Henri. From carjay at gmx.net Thu Dec 25 07:49:50 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu Dec 25 07:49:54 2008 Subject: [sldev] [Compiling/Error] Error: the command 'make' exited with status 2 In-Reply-To: <2da30a0e0812250348i20f31450wdbc7037657933ff7@mail.gmail.com> References: <2da30a0e0812250348i20f31450wdbc7037657933ff7@mail.gmail.com> Message-ID: <4953AB9E.2090908@gmx.net> Hello Mikkel, could you please post the complete log? It only shows that make stops but it does not say where and why. Sometimes the position of the error is several lines before make actually stops. Regards, Carsten Mikkel Hansen wrote: > Well, I'm relatively new to C++, compiling, mailinglists, etc... > Anyway, when I try to compile the viewer I get an error. I'm on Linux > Mint using cmake-SL to build the client. I've applied one patch > (https://jira.secondlife.com/browse/VWR-10001) to get past an error > earlier, however, now I'm stuck again. D: > > I get the following error: > > ... > [ 31%] Building CXX object llmessage/CMakeFiles/llmessage.dir/patch_dct.o > [ 31%] Building CXX object llmessage/CMakeFiles/llmessage.dir/patch_idct.o > Linking CXX static library libllmessage.a > make[2]: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' > [ 31%] Built target llmessage > make[1]: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' > make: *** [all] Error 2 > make: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' > Error: the command 'make' exited with status 2 > > > I am not sure if you need the version name/whatever I am trying to > compile, although if you do, I'll tell you. :p > > Thanks > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From rdw at lindenlab.com Thu Dec 25 10:09:06 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Thu Dec 25 10:09:14 2008 Subject: [sldev] Getting started with eventlet and spawning... In-Reply-To: <558124520812242105g16b0bef8sb3e9989d29052cd3@mail.gmail.com> References: <558124520812242105g16b0bef8sb3e9989d29052cd3@mail.gmail.com> Message-ID: <4953CC42.7000607@lindenlab.com> Hey Sam, we actually created a separate mailing list for eventlet-related stuff, because sldev is pretty much for viewer development only. It's eventletdev@lists.secondlife.com . Cross-posting there for ya. I'm not really an expert on spawning, but it looks like you might have more success not calling wrap_socket_with_coroutine_socket from within FetchApp. Spawning should handle that for you, modulo the command-line arguments given it. That's just a shot in the dark though. And, merry christmas! Sam's Lists wrote: > (Yes I am spending Christmas Eve on exactly this... :) > > So, I'm trying to set started porting an existing wsgi application > I've written. The existing app uses Twisted and runs under CherryPy's > wsgi server. I thought eventlet and spawning would be a nice > replacement for twisted and cherrypy respectively. > > But I'm having trouble. The example from the docs for downloading > three pages works fine. But when I try and embed the example as a > wigi app I can't make it work. I've tried a bunch of variations, but > here's the current one. > > #!/usr/bin/env python > > urls = ["http://www.google.com", > "http://wiki.secondlife.com", > "http://us.i1.yimg.com"] > > import time > from eventlet import coros, httpc, util > from webob import Request, Response > > def fetch(url): > print "%s fetching %s" % (time.asctime(), url) > x = httpc.get(url) > print x > print "%s fetched %s" % (time.asctime(), url) > > def FetchApp(environ, start_response): > util.wrap_socket_with_coroutine_socket() > pool = coros.CoroutinePool(max_size=4) > waiters = [] > for url in urls: > waiters.append(pool.execute(fetch, url)) > for waiter in waiters: > waiter.wait() > resp = Response("done") > return resp(environ, start_response) > > > Now when I run this as: > % spawn test_eventlet.FetchApp > > and then I make a request with my web browser, I get the folowing output: > > (18686) **** Controller starting up at Thu Dec 25 04:52:16 2008 > (18686) spawning 1 children with > /usr/lib/python2.5/site-packages/Spawning-0.8.7-py2.5.eg > > g/spawning/spawning_child.pyc > (18686) serving wsgi with configuration: > (18686) {'app': 'test_eventlet.FetchApp', > (18686) 'app_factory': 'spawning.wsgi_factory.app_factory', > (18686) 'args': ['test_eventlet.FetchApp'], > (18686) 'deadman_timeout': 120, > (18686) 'dev': True, > (18686) 'host': '', > (18686) 'middleware': [], > (18686) 'num_processes': 1, > (18686) 'port': 8080, > (18686) 'processpool_workers': 0, > (18686) 'source_directories': ['/home/sam/eventlet-fetcher'], > (18686) 'threadpool_workers': 10, > (18686) 'watch': None} > (18687) reloader watching sys.modules > (18687) using 10 threads > (18687) wsgi starting up on http://0.0.0.0:8080/ > Thu Dec 25 04:52:20 2008 fetching http://www.google.com > Thu Dec 25 04:52:20 2008 fetching http://wiki.secondlife.com > Thu Dec 25 04:52:20 2008 fetching http://us.i1.yimg.com > Traceback (most recent call last): > File > "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/hubs/hub.py", > li > ne 294, in fire_timers > timer() > File > "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/timer.py", > line > 77, in __call__ > cb(*args, **kw) > File > "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/greenlib.py", > line 314, in switch > rval = other.switch(value, exc) > error: cannot switch to a different thread > Timer raised: Timer(0, , > *(, [(2, 1, 6, '', > ('64.233.161.99', 80)), (2, 1, 6, '', ('64.233.161.104', 80)), (2,1, > 6, '', ('64.233.161.147', 80))]), **{}) > Traceback (most recent call last): > File > "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/hubs/hub.py", > line 294, in fire_timers > timer() > File > "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/timer.py", > line77, in __call__ > cb(*args, **kw) > File > "/usr/lib/python2.5/site-packages/eventlet-0.8-py2.5.egg/eventlet/greenlib.py", > line 314, in switch > rval = other.switch(value, exc) > error: cannot switch to a different thread > Timer raised: Timer(0, , > *(, [(2, 1, 6, '', > ('204.245.162.32', 80)), (2, 1, 6, '', ('204.245.162.27', 80))]), **{}) > > What at I doing wrong? > > Thanks > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From TammyNowotny at mac.com Thu Dec 25 10:56:43 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Thu Dec 25 10:56:50 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <20081225160840.30c2ee2a.sldev@free.fr> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <20081225160840.30c2ee2a.sldev@free.fr> Message-ID: <4953D76B.8080701@mac.com> US law requires you to collect certain indentifying info if you regularly exchange RL dollars from a person or company. (You also have to keep that info confidential, however.) Linden Lab is bound by that law and would be even if it moved their servers overseas. Also, PayPal is not anonymous either. Ho ho ho!! Henri Beauchamp wrote: > > > Nope... All what LL got and needs is an email address > (also used for Paypal money exchanges) and my IP when > I connect to the grid. They don't have anything else. > > You will also notice that, like would be epxected in most > UE contries and to comply with their privacy laws, LL is > not even requesting a RL name any more in their resident > registration forms. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081225/26b4201d/attachment.htm From kf6kjg at gmail.com Thu Dec 25 23:01:38 2008 From: kf6kjg at gmail.com (Ricky) Date: Thu Dec 25 23:01:42 2008 Subject: [sldev] Failed build on x86_64, failed including glib? Message-ID: <3bb9647e0812252301m412e0f07o81315c7e59167694@mail.gmail.com> Ok, I've been working out a recipe for compiling the client. I got all the way to where I could call make and got the following lines at the top of a very long error list: [ 18%] Building CXX object llmedia/CMakeFiles/llmedia.dir/llmediamanager.o In file included from /home/ricky/SLDev64/linden/indra/llmedia/llmediaimplgstreamer.h:44, from /home/ricky/SLDev64/linden/indra/llmedia/llmediamanager.cpp:38: /home/ricky/SLDev64/linden/indra/../libraries/x86_64-linux/include/gstreamer-0.10/gst/gst.h:27:18: error: glib.h: No such file or directory My system: 2.6.25-gentoo-r7 #3 SMP Mon Nov 10 20:40:02 PST 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux My process: (I'm documenting the steps so I can build a shellscript to do it all for me...) # Do an SVN update. # Download the artwork referenced by the line matching '^SLASSET_ART=' from the linden/doc/asset_urls.txt # Extract the artwork. # Build the Release edition client: # cd linden/indra # ./develop.py -t Release -N # cd viewer-linux-$(arch)-release # make Any ideas? Ricky aka Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081225/c62e1d6a/attachment.htm From dnbyena at gmail.com Fri Dec 26 00:10:57 2008 From: dnbyena at gmail.com (Khyota) Date: Fri Dec 26 00:11:04 2008 Subject: [sldev] Failed build on x86_64, failed including glib? In-Reply-To: <3bb9647e0812252301m412e0f07o81315c7e59167694@mail.gmail.com> References: <3bb9647e0812252301m412e0f07o81315c7e59167694@mail.gmail.com> Message-ID: <200812260310.58155.dnbyena@gmail.com> >Any ideas? You forgot to add --standalone to # ./develop.py -t Release -N. so # ./develop.py --standalone -t Release -N? your trying to compile against the precompiled librarys, and glib isnt included for x86_64 yet. you may also need to grab the libs, SDL, and glh_linear packages from install.xml SDL contains the missing cursors which arent in artwork for some reason, and glh_linear is needed but isnt downloaded in standalone, the libs contains fonts but if your replacing them its fine. If your compiling svn trunk you will need to compile libndofdev seperatly and LL does not provide the source so here it is. http://www.aaue.dk/~janoc/files/software/linux/spacenav/libndofdev-0.2.tar.gz (thanks jan) Thats extra work for going x86_64 these days :/ you mite also want to check out the gentoo ebuild, might also help solve the dependancy mess and give you a 'skeleton' for your script, its on the zugaina overlay, but heres a url to the latest one too. http://gentoo.zugaina.org/portage/games- simulation/secondlife/secondlife-1.22.4_rc.ebuild Happy building! Khyota From infinity at lindenlab.com Fri Dec 26 09:01:38 2008 From: infinity at lindenlab.com (infinity@lindenlab.com) Date: Fri Dec 26 09:01:41 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <329370.24473.qm@web63808.mail.re1.yahoo.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> Message-ID: <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> okay... i was trying to avoid entering this discussion, but here i go. lemme preface my comments with a bit of my background... blah blah blah... bell canada... blah blah blah... rsadsi (back when it was a real engineering company)... certicom... cigital... meson group... managed borland's secure product development group... etc. so... while only an idiot would claim to be "an expert" in all areas of internet security, i've as much right to say i know something about these issues as the next guy. the reason the doctrine of "fair disclosure" was developed was to provide some protection for the organization developing the vulnerable software as well as encouraging the security research community to report vulnerabilities and their related exploits. the reasoning went something like this... back in the go-go 90's there was a cottage industry of private security research. i'm not talking just hackers in basements trying to figure out how systems work for fun, but groups of consulting engineers trying to prove to the world that they have the ability to delve into the inner workings of software, find some problems and figure out how to exploit (and later repair) them. real money. real engineering practice. embarrassing the "big guys" and getting the press to look at you as you described problems in popular software tended to have a positive effect on these company's bottom lines. all software has vulnerabilities. sorry. it's the truth. the vulnerabilities sometimes come from "sloppy" coding, but increasingly problems emerge from integrating multiple components with insufficient abstractions to model security behavior. so it might be advantageous to cast the discussion in this light. given that the LL viewer code includes X lines of code and there's a non-zero per-line chance of introducing a vulnerability, and that we use several libraries maintained by 3rd parties (with Y lines of code), we must have Z undiscovered vulnerabilities in the LL viewer. some of the vulnerabilities are no doubt of "low impact", but i've found a good working assumption is, "there's at least one more serious vulnerability in your code." (it seems to be true more often than not.) because this vulnerability is yet to be discovered does not limit it's eventual impact. so.. for the sake of discussion.. let's assume the following discussion is true "there is a serious exploit in the current LL viewer code which will lead to disclosure of sensitive user information, compromise of systems running the client, illegal asset or funds transfer and global thermonuclear war." if a security researcher out in the trenches discovers a vulnerability, disclosing it widely before a fix is available is clearly bad for not only Linden, but for the user community. nuclear war is generally bad for everybody. let's turn it around... lets say that your wallet has an undisclosed vulnerability that allows 10%-50% of it's contents to be magically transported to Joey Soprano's bank account. who do _you_ want to know about this vulnerability. "fair disclosure" provides direction to security researchers, asking them to report the problem to people who can create a fix in a reasonable time frame. i've painted some pretty dire ramifications of vulnerabilities... nuclear war and extensive funds loss. there is no reason to believe either of these events would be the result of a bug in the LL viewer code, but it is sometimes nice to "plan for the absurdly worst." and.. btw.. microsoft DOES NOT always announce security vulnerabilities as they learn about them. the fact that the viewer is open is orthogonal to the discussion of fair disclosure. we're talking about what do you do when you notice a vulnerability, not who has the ability to look at the source code and search for a vulnerability. under the doctrine of fair disclosure, the answer to the former is "anyone who can reasonably be expected to assist in the remediation of the vulnerability." i would argue that as an organization, Linden would be disproportionally affected by multiple exploits in the viewer code, which would encourage Linden to move heaven and earth to get these things fixed in a reasonable time frame. so... this is just a long winded discussion to support the following statement: "telling everybody about a security vulnerability before remediation is available is bad." > So who decides who is "good" or "bad" to receive or > not to receive security > bulletins? I think it's the wrong way to follow an > Apple's approach to keep > security issues secret until they possibly are fixed. > I like the approach to > openly disclose security gaps, make users aware of > imminent risk, and try to > fix issues ASAP with help of the users. That's how > Microsoft handles it. > > Surely there are defenders of both camps. But SL is > now opensource. I think > the only way to properly handle security issues > detected is to make > everybody aware of them. Not to select a few deemed > "white hats" to be > informed but all people who work with the code. Be > ensured the "black hats" > do the same. > > One additional point @ Henri. You are registered with > your RL details @ LL. > As such I don't see a point with anonymity here. There > is none. > > Merry Xmas! > > Boy > > http://my.opera.com/boylane > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From kf6kjg at gmail.com Fri Dec 26 10:04:20 2008 From: kf6kjg at gmail.com (Ricky) Date: Fri Dec 26 10:04:24 2008 Subject: [sldev] Failed build on x86_64, failed including glib? In-Reply-To: <200812260310.58155.dnbyena@gmail.com> References: <3bb9647e0812252301m412e0f07o81315c7e59167694@mail.gmail.com> <200812260310.58155.dnbyena@gmail.com> Message-ID: <3bb9647e0812261004j5264d095q5285535259c02dc3@mail.gmail.com> Thanks! I'll check out the overlay, and try your suggestions. Ricky aka Cron Stardust On Fri, Dec 26, 2008 at 12:10 AM, Khyota wrote: > >Any ideas? > You forgot to add --standalone to # ./develop.py -t Release -N. so # > ./develop.py --standalone -t Release -N? your trying to compile against the > precompiled librarys, and glib isnt included for x86_64 yet. > > you may also need to grab the libs, SDL, and glh_linear packages from > install.xml SDL contains the missing cursors which arent in artwork for > some > reason, and glh_linear is needed but isnt downloaded in standalone, the > libs > contains fonts but if your replacing them its fine. > > If your compiling svn trunk you will need to compile libndofdev seperatly > and > LL does not provide the source so here it is. > > http://www.aaue.dk/~janoc/files/software/linux/spacenav/libndofdev-0.2.tar.gz > (thanks jan) > > Thats extra work for going x86_64 these days :/ > you mite also want to check out the gentoo ebuild, might also help solve > the > dependancy mess and give you a 'skeleton' for your script, its on the > zugaina > overlay, but heres a url to the latest one too. > > http://gentoo.zugaina.org/portage/games- > simulation/secondlife/secondlife-1.22.4_rc.ebuild > > Happy building! > > Khyota > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081226/9e112483/attachment.htm From robla at lindenlab.com Fri Dec 26 10:09:16 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Dec 26 10:09:23 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <105c09f0812241413k4ba6f682lb989af81b37e52e2@mail.gmail.com> References: <49518443.7050107@lindenlab.com> <105c09f0812241413k4ba6f682lb989af81b37e52e2@mail.gmail.com> Message-ID: <49551DCC.7040403@lindenlab.com> Hi everyone, Great discussion! I think it's worth clarifying the range of options we're considering, and to state explicitly what options are not on the table. First the non-options. The following options are really not viable, and aren't on the table, but have been discussed in this thread, so they're worth pointing out as non-options: Non-option A: disclose vulnerabilities to everyone as soon as we're aware of them. As Infinity points out, this is reckless, and should only be done in the event that there's evidence a vulnerability is already being widely exploited, and even then, the nature of the disclosure should be to provide enough information that people can keep themselves safe, rather than all of the information to try the exploit themselves. Non-option B: early disclosure group that gets notice of vulnerabilities weeks or months before the general public. Our intention is to give a slight headstart for viewer distributors, not to delay general disclosure for longer than necessary. Now, here's what we're considering. Option 1: Linden Lab creates a vulnerability early disclosure group, admitting people into the group based on their need to know and track record of reliability, honesty and discretion. "Need to know" is limited to people or organizations that distribute viewers used by a wide audience, or some other very compelling reason to know. This group would get notice of some details regarding a vulnerability when Linden Lab becomes aware of a problem, and receive the patch early when Linden Lab has an untested fix that's ready for incorporation. The time between early disclosure (when this group knows about a problem) and general disclosure (when the general public knows about the problem) would likely be a period best measured in days, not weeks or months. Option 2: similar to option #1, with the addition of an explicit, signed non-disclosure agreement as a prerequisite for joining the group. Option 3: Linden Lab only discloses vulnerabilities when a patch a fix is available (no early disclosure group). In evaluating the three options above, I'd like folks to think it through both ways. What sort of requirements would you want placed on yourself for joining, and what sort of requirement would you want placed on others. In particular, option #3 may be what you should recommend if you don't trust that Linden Lab can select an early disclosure group in a way that exploit information won't fall into the wrong hands prior to a fix being available. Similarly, you may prefer option #2 if you want to make sure that everyone in the group is explicitly subject to legal remedy for irresponsible disclosure. Rob From sheet.spotter at gmail.com Fri Dec 26 11:08:26 2008 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Fri Dec 26 11:08:28 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: I made a few assumptions that may not be shared by everyone: 1. Vulnerabilities must not be publicly disclosed before they are corrected. 2. Vulnerabilities must be promptly assessed and mitigated by as small a group as possible (i.e., on a need-to-know basis). 3. Any limited disclosure of vulnerabilities is shortly followed by a broader, more public disclosure. I see the disclosure of vulnerabilities as similar to the disclosure of your password. Publicly disclosing or sharing your password before you can change it is unwise. Failure to publicly disclose a vulnerability (or your password) is not an example of "security through obscurity"; it's simply prudent to protect that information. Vulnerabilities that are under investigation must be kept under wraps. Keeping them under wraps is not intended to deceive anyone or to deprive anyone of critical information. It is a necessary step until the problem can be resolved, just as maintaining the confidentiality of your password is necessary. Limited disclosure of security bulletins is also an important step towards the public disclosure. It does not replace the public disclosure. Limited disclosure ensures all products -- not just LL products -- have an opportunity to address the vulnerability before it's widely known. Ideally any limited disclosure would only occur once LL was capable of identifying anyone attempting to use the vulnerability. If there ever was a truly exceptional case where a vulnerability was so severe that it needed to be publicly disclosed before it was corrected, then the system should be shut down until the issue was resolved. I have always taken security and vulnerabilities very seriously. I would love to know about them in advance, but I recognize and accept that it's not appropriate for me to know about them in advance. I *want* to know about them, I don't *need* to know about them. Sheet Spotter -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of infinity@lindenlab.com Sent: December 26, 2008 11:02 AM To: Boy Lane Cc: sldev@lists.secondlife.com Subject: Re: [sldev] Viewer security vulnerability disclosure group [...] "telling everybody about a security vulnerability before remediation is available is bad." > So who decides who is "good" or "bad" to receive or > not to receive security > bulletins? [...] > > I think the only way to properly handle security issues > detected is to make everybody aware of them. [...] > > Merry Xmas! > > Boy > From ordinal.malaprop at fastmail.fm Fri Dec 26 11:19:01 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Dec 26 11:19:05 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: Vulnerabilities are not like passwords. Passwords cannot be discovered by experimentation and analysis (well, not if they are good passwords). Passwords provide no risk unless actively disclosed. Vulnerabilities _do_ constitute an active risk regardless of whether they are disclosed or not, as people looking for them can (and will) find them eventually, and once they have, the details will spread explosively. Exposing them before they are fixed at least gives users the chance to defend themselves before this happens, even if that means closing down systems. If there is a vulnerability in SL which was not already widely known - and how can one tell? - and which LL knew that they could fix quite shortly, then it would be best to err towards keeping it quiet until it was fixed. If there is not progress on fixing a vulnerability then it needs to be publicised so that people can account for it. On 26 Dec 2008, at 19:08, Sheet Spotter wrote: > I made a few assumptions that may not be shared by everyone: > 1. Vulnerabilities must not be publicly disclosed before they are > corrected. > > 2. Vulnerabilities must be promptly assessed and mitigated by as > small a > group as possible (i.e., on a need-to-know basis). > 3. Any limited disclosure of vulnerabilities is shortly followed by a > broader, more public disclosure. > > I see the disclosure of vulnerabilities as similar to the disclosure > of your > password. Publicly disclosing or sharing your password before you > can change > it is unwise. > > Failure to publicly disclose a vulnerability (or your password) is > not an > example of "security through obscurity"; it's simply prudent to > protect that > information. > > Vulnerabilities that are under investigation must be kept under wraps. > Keeping them under wraps is not intended to deceive anyone or to > deprive > anyone of critical information. It is a necessary step until the > problem can > be resolved, just as maintaining the confidentiality of your > password is > necessary. > > Limited disclosure of security bulletins is also an important step > towards > the public disclosure. It does not replace the public disclosure. > > Limited disclosure ensures all products -- not just LL products -- > have an > opportunity to address the vulnerability before it's widely known. > > Ideally any limited disclosure would only occur once LL was capable of > identifying anyone attempting to use the vulnerability. > > If there ever was a truly exceptional case where a vulnerability was > so > severe that it needed to be publicly disclosed before it was > corrected, then > the system should be shut down until the issue was resolved. > > I have always taken security and vulnerabilities very seriously. I > would > love to know about them in advance, but I recognize and accept that > it's not > appropriate for me to know about them in advance. I *want* to know > about > them, I don't *need* to know about them. > > > Sheet Spotter > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of > infinity@lindenlab.com > Sent: December 26, 2008 11:02 AM > To: Boy Lane > Cc: sldev@lists.secondlife.com > Subject: Re: [sldev] Viewer security vulnerability disclosure group > > [...] > > "telling everybody about a security vulnerability before remediation > is > available is bad." > >> So who decides who is "good" or "bad" to receive or >> not to receive security >> bulletins? [...] >> >> I think the only way to properly handle security issues >> detected is to make everybody aware of them. [...] >> >> Merry Xmas! >> >> Boy >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From GordonWendt at gmail.com Fri Dec 26 11:40:45 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri Dec 26 11:40:49 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49551DCC.7040403@lindenlab.com> References: <49518443.7050107@lindenlab.com> <105c09f0812241413k4ba6f682lb989af81b37e52e2@mail.gmail.com> <49551DCC.7040403@lindenlab.com> Message-ID: <493033a70812261140i4e409527qd371ce51029babcb@mail.gmail.com> On Fri, Dec 26, 2008 at 1:09 PM, Rob Lanphier wrote: > Option 3: Linden Lab only discloses vulnerabilities when a patch a fix > is available (no early disclosure group). I think that is the best option. As soon as LL has a fix release a patch as well as a full disclosure of what the vulnerability is/was, how it was exploited and how to update to close it. On Fri, Dec 26, 2008 at 2:08 PM, Sheet Spotter wrote: > > I see the disclosure of vulnerabilities as similar to the disclosure of > your > password. Publicly disclosing or sharing your password before you can > change > it is unwise. I would list the numerous reasons how your entire post is just wrong but I think Ordinal did a better job quickly summing it up than I could. On Fri, Dec 26, 2008 at 2:19 PM, wrote: > Vulnerabilities are not like passwords. Passwords cannot be discovered by > experimentation and analysis (well, not if they are good passwords). > Passwords provide no risk unless actively disclosed. > > Vulnerabilities _do_ constitute an active risk regardless of whether they > are disclosed or not, as people looking for them can (and will) find them > eventually, and once they have, the details will spread explosively. > Exposing them before they are fixed at least gives users the chance to > defend themselves before this happens, even if that means closing down > systems. > > If there is a vulnerability in SL which was not already widely known - and > how can one tell? - and which LL knew that they could fix quite shortly, > then it would be best to err towards keeping it quiet until it was fixed. If > there is not progress on fixing a vulnerability then it needs to be > publicised so that people can account for it. I agree wholeheartedly. If an issue can be fixed shortly then LL should put the devs on it and get it fixed then (per what I said above) release a patch and a full disclosure on the issue as well as patch/upgrade steps. If it's something without a quick fix that can be fixed or even just mitigated client side I trust Nicholaz and the other 3rd party viewer makers more than LL to get a good patch out to their users. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081226/cd986a26/attachment.htm From Celierra at gmail.com Fri Dec 26 12:18:03 2008 From: Celierra at gmail.com (Celierra Darling) Date: Fri Dec 26 12:18:05 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: On Fri, Dec 26, 2008 at 2:19 PM, wrote: > Vulnerabilities _do_ constitute an active risk regardless of whether they > are disclosed or not, as people looking for them can (and will) find them > eventually, and once they have, the details will spread explosively. > Exposing them before they are fixed at least gives users the chance to > defend themselves before this happens, even if that means closing down > systems. I'm not sure this follows. There's a difference between exposing enough details to exploit, reproduce, and fix a vulnerability, and providing a way to prevent or mitigate possible exploits. I think we're just talking about the former, i.e. to whom LL can give details like "there exists a buffer overflow near llhippos.cpp:123, triggered by sending a malformed LLSomeMessage". Disclosing the vulnerability to everyone like that will not necessarily help with defense, and may likely hinder it by decreasing the time one has to implement workarounds. On Fri, Dec 26, 2008 at 2:40 PM, Gordon Wendt wrote: > If it's > something without a quick fix that can be fixed or even just mitigated > client side I trust Nicholaz and the other 3rd party viewer makers more than > LL to get a good patch out to their users. I'm confused at the distinction here. If I take "without a quick fix" to mean something like "LL thinks the ETA for the fix is far enough in the future that sending separate disclosure to third-party viewer maintainers makes sense", this sounds a lot like an early disclosure group to me. What's the difference? Celierra From ordinal.malaprop at fastmail.fm Fri Dec 26 12:27:24 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Dec 26 12:27:31 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: <13AE7B55-FBC8-4B23-B1CC-E42E81413862@fastmail.fm> On 26 Dec 2008, at 20:18, Celierra Darling wrote: > On Fri, Dec 26, 2008 at 2:19 PM, > wrote: >> Vulnerabilities _do_ constitute an active risk regardless of >> whether they >> are disclosed or not, as people looking for them can (and will) >> find them >> eventually, and once they have, the details will spread explosively. >> Exposing them before they are fixed at least gives users the chance >> to >> defend themselves before this happens, even if that means closing >> down >> systems. > > I'm not sure this follows. There's a difference between exposing > enough details to exploit, reproduce, and fix a vulnerability, and > providing a way to prevent or mitigate possible exploits. I think > we're just talking about the former, i.e. to whom LL can give details > like "there exists a buffer overflow near llhippos.cpp:123, triggered > by sending a malformed LLSomeMessage". Disclosing the vulnerability > to everyone like that will not necessarily help with defense, and may > likely hinder it by decreasing the time one has to implement > workarounds. I don't see how it would decrease the time one has to implement workarounds, I'm afraid - could you elaborate? One can't implement a workaround without actually knowing about an exploit, so the time will always be less (than infinite) when one does know about it. The question is whether exposing an exploit will mean somebody who otherwise wouldn't now manages to exploit the exploit before the victim can fix things. In practice I think history indicates that discovered exploits tend to propagate through media quite apart from security lists. From hawk.carter at unix-dev.de Fri Dec 26 15:34:14 2008 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Fri Dec 26 15:34:02 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: ----- Original Message ----- From: Cc: Sent: Friday, December 26, 2008 6:01 PM Subject: Re: [sldev] Viewer security vulnerability disclosure group > so... while only an idiot would claim to be "an expert" in all areas of > internet security, i've as much right to say i know something about these > issues as the next guy. Selfpromoting as an an Specialist is the same Way. > "telling everybody about a security vulnerability before remediation is > available is bad." There is no need to tell everyone the exact Issue of an Leak, but to say "We have a leak/vuna. etc in Billing, Userdatabase etc" is a important thing. The other Way is just a lie to Residents..while the Data gets stolen or what ever. my 2 Cents. From ordinal.malaprop at fastmail.fm Fri Dec 26 15:44:26 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Dec 26 15:44:30 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: On 26 Dec 2008, at 17:01, infinity@lindenlab.com wrote: > so.. for the sake of discussion.. let's assume the following > discussion is > true "there is a serious exploit in the current LL viewer code which > will > lead to disclosure of sensitive user information, compromise of > systems > running the client, illegal asset or funds transfer and global > thermonuclear war." > > if a security researcher out in the trenches discovers a > vulnerability, > disclosing it widely before a fix is available is clearly bad for > not only > Linden, but for the user community. nuclear war is generally bad for > everybody... > > ..."telling everybody about a security vulnerability before > remediation is > available is bad." I am sorry but I'm afraid that that really doesn't make the case at all. Your post ignores any potential benefit granted to users by knowing what an exploit is and how to counteract it before it is once- and-for-all fixed on the server side by LL. The overall impact is still better if users have the chance to patch and adapt before fixes are available if fixes don't arrive almost immediately. Which they may well not do. From carjay at gmx.net Fri Dec 26 16:43:54 2008 From: carjay at gmx.net (Carsten Juttner) Date: Fri Dec 26 16:43:57 2008 Subject: [sldev] [Compiling/Error] Error: the command 'make' exited with status 2 In-Reply-To: <2da30a0e0812260834y612dac97he02e9d5d9d14c356@mail.gmail.com> References: <2da30a0e0812250348i20f31450wdbc7037657933ff7@mail.gmail.com> <4953AB9E.2090908@gmx.net> <2da30a0e0812260834y612dac97he02e9d5d9d14c356@mail.gmail.com> Message-ID: <49557A4A.2020109@gmx.net> Hello Mikkel, easiest is to simply redirect any (stdout and stderr) output to a file by typing this: make > log.txt 2>&1 Carsten Mikkel Hansen wrote: > Hi, sorry about the slow response. > > How do I post the complete log? I only see a few lines in the terminal. > > Thanks, > Mikkel > > Carsten Juttner wrote > > Hello Mikkel, > > could you please post the complete log? > > It only shows that make stops but it does not say where and why. > > Sometimes the position of the error is several lines before make > actually stops. > > > Regards, > Carsten > > > > Mikkel Hansen wrote: > > Well, I'm relatively new to C++, compiling, mailinglists, > etc... Anyway, when I try to compile the viewer I get an > error. I'm on Linux Mint using cmake-SL to build the client. > I've applied one patch > (https://jira.secondlife.com/browse/VWR-10001) to get past an > error earlier, however, now I'm stuck again. D: > > I get the following error: > > ... > [ 31%] Building CXX object > llmessage/CMakeFiles/llmessage.dir/patch_dct.o > [ 31%] Building CXX object > llmessage/CMakeFiles/llmessage.dir/patch_idct.o > Linking CXX static library libllmessage.a > make[2]: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' > [ 31%] Built target llmessage > make[1]: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' > make: *** [all] Error 2 > make: Leaving directory `/usr/src/SL/indra/viewer-linux-i686' > Error: the command 'make' exited with status 2 > > > I am not sure if you need the version name/whatever I am > trying to compile, although if you do, I'll tell you. :p > > Thanks > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > From boy.lane at yahoo.com Fri Dec 26 19:16:47 2008 From: boy.lane at yahoo.com (Boy Lane) Date: Fri Dec 26 19:16:50 2008 Subject: [sldev] Viewer security vulnerability disclosure group References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: <104458.53743.qm@web63804.mail.re1.yahoo.com> > so... this is just a long winded discussion to support the following > statement: > > "telling everybody about a security vulnerability before remediation is > available is bad." And this is simply wrong. Not only wrong but unacceptable. We don't need to go through a long list of historical events or personal experiences. Let's just keep it down to the facts. LL decided to put the SecondLife code into?open source, available for everyone everywhere.?As such any approach of security through obscurity is doomed to fail. By putting SL into open source, LL took on a huge responsibility as active developer and as contributor to the open source community. Thanks to that SL code is now in one way or the other used by millions of users in hundreds or thousands of grids worldwide. I understand that LL has no interest in supporting the competition like the opensim grids, and as you wrote LL has no interest to expose themselves to possible (commercial) risk. But asI just said, you made the decision?earlier to be part of the opensource development. And you benefit largely from it. It is?a?two way road. I'd expect LL to provide regular security bulletins in an organized way, accessible to all users who?would be interested in them. That does not mean a detailed?piece of code,?but a clear description of the?vulnerability and?the risk. A good distribution list?reaching dedicated people would indeed be the SLDev mailing list. So that developers can decide?what to do, perhaps help to fix it in faster way than LL would be able to or is unwilling to do, or if this is not possible to provide recommendations such as not to use a particular version of the viewer. I remember that last security disaster in the 1.20.17 version. LL decided to work behind closed doors.?Even though a fix was internally available it was not provided in source / patch form to 3rd party developers, leaving 10's?if not 100's of thousand users vulnerable. It was only made available several days later through?obscure channels to a handful of developers who asked for. And it was half hearted as LL decided not to backport the security patches to the 1.19 pre-windlight viewers but left that task completely to?the developers of alternative viewers. The only way to mitigate the risk was to tell people not to use in our case the Cool Viewer as the vulnerability and risks were?unknown. Which led to a worse development by many users falling back to older, unpatched versions and high likely many still use them today.? So, to come back to the beginning.?NOT to provide security information before a "remedation is available" is bad. It is not only bad, but if LL knows about a security threat and keeps it?intentionally secret, I would question if this is in the interest?and in good faith not only for LL and SecondLife users but for the whole opensource community?LL decided to be part of. In the past LL also left security critical work completely to 3rd party developers as just explained. I guess that will be covered under "Quality Assurance". Under fair disclosure I would understand an early warning mechanism,?not limited to only a handful of people willing to sign an NDA with LL as the code is?not in LL's but in?opensource hands.?This early warning mechanism should distribute information about ALL security vulnerabilities found and potential risk involved. And it should?work in both ways for the benefit of all. Boy http://my.opera.com/boylane -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081226/c6d05009/attachment.htm From Celierra at gmail.com Fri Dec 26 20:50:56 2008 From: Celierra at gmail.com (Celierra Darling) Date: Fri Dec 26 20:51:05 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <13AE7B55-FBC8-4B23-B1CC-E42E81413862@fastmail.fm> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <13AE7B55-FBC8-4B23-B1CC-E42E81413862@fastmail.fm> Message-ID: On Fri, Dec 26, 2008 at 3:27 PM, wrote: > One can't implement a workaround without > actually knowing about an exploit... There are plenty of cases where one can release a workaround or patch without giving away how to exploit the vulnerability. One example is the Kaminsky-found DNS hole (patch: randomize ports). Another is the Quicktime-to-SL hole (workaround: disable playback via Quicktime). Although you get notified that there *exists* a vulnerability somewhere there, you're not getting details at the level of "the bug is at llhippos.cpp:123....". The logic goes, if you release only the workarounds to the public instead of the exploit details, you make crackers' lives a bit harder, and so give your users more time to apply the patches/workarounds before exploits get into the wild. > The question is whether exposing an exploit will mean somebody who otherwise > wouldn't now manages to exploit the exploit before the victim can fix > things. In practice I think history indicates that discovered exploits tend > to propagate through media quite apart from security lists. I don't see why an early disclosure group would be much of a hindrance in a zero-day case. Suppose an exploit is floating in the wild already, and LL for some reason does early disclosure anyway. Then at least one of the teams of developers (third party and/or LL) would likely think up some sort of patch or workaround. If nobody can figure out how to mitigate it (which would be rather extraordinary!), then I don't see why they wouldn't immediately go for public help in coming up with one. Are you worried about the delay between the two, or am I missing something? If you are, then perhaps all that's needed is recognition that in a case where an exploit is already actively going around, there's not much gain in releasing to a limited group first (since 'they' already have the exploit). But I'd think that to be rather self-evident, to be honest. Celierra From GordonWendt at gmail.com Fri Dec 26 21:13:22 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri Dec 26 21:13:27 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: <493033a70812262113x1fdfc7b8ma1e327836d61605@mail.gmail.com> > On Fri, Dec 26, 2008 at 2:40 PM, Gordon Wendt > wrote: > > If it's > > something without a quick fix that can be fixed or even just mitigated > > client side I trust Nicholaz and the other 3rd party viewer makers more > than > > LL to get a good patch out to their users. > > I'm confused at the distinction here. If I take "without a quick fix" > to mean something like "LL thinks the ETA for the fix is far enough in > the future that sending separate disclosure to third-party viewer > maintainers makes sense", this sounds a lot like an early disclosure > group to me. What's the difference? > > Celierra My bad for not being more clear, by disclosing the problem I meant to everyone not just to the "select" group of people. If LL can't get a fix out in time and especially if it's something that can be mitigated then everyone should know about it so that they can at least do their best to mitigate their exposure to it and if it's a client side issue possibly patch it themselves before LL can. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081227/c0753dc9/attachment.htm From tateru.nino at gmail.com Fri Dec 26 22:31:25 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Dec 26 22:31:51 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <493033a70812262113x1fdfc7b8ma1e327836d61605@mail.gmail.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <493033a70812262113x1fdfc7b8ma1e327836d61605@mail.gmail.com> Message-ID: <4955CBBD.8030805@gmail.com> Gordon Wendt wrote: > > On Fri, Dec 26, 2008 at 2:40 PM, Gordon Wendt > > wrote: > > If it's > > something without a quick fix that can be fixed or even just > mitigated > > client side I trust Nicholaz and the other 3rd party viewer > makers more than > > LL to get a good patch out to their users. > > I'm confused at the distinction here. If I take "without a quick fix" > to mean something like "LL thinks the ETA for the fix is far enough in > the future that sending separate disclosure to third-party viewer > maintainers makes sense", this sounds a lot like an early disclosure > group to me. What's the difference? > > Celierra > > > My bad for not being more clear, by disclosing the problem I meant to > everyone not just to the "select" group of people. If LL can't get a > fix out in time and especially if it's something that can be mitigated > then everyone should know about it so that they can at least do their > best to mitigate their exposure to it and if it's a client side issue > possibly patch it themselves before LL can. What are people's thoughts on issues that cannot be mitigated by the user? While there's a lot of people couldn't manage to disable quicktime on their own (and perhaps half of SL users have never even heard of that exploit), there's still a whole class of security issues about which the user may be able to do nothing (some examples were dealt with recently). Pending any better information, I'm guessing the Lab's best effort response to a serious viewer security exploit would be 48-72 hours. The exploit needs to be confirmed and found; options to fix it have to be discussed; any concomitant factors need to be taken into account; the fix has to be *tested* to make sure it actually fixes the exploit and any obvious variations. Then formal QA starts to make sure that the viewer still works properly in all other ways - because, heck, the fix may have had an unforseen side-effect. Somewhere around the time this last QA phase begins, I'm guessing is when it is proposed that the third-parties on the disclosure list get notified, which would have their own viewers ready around the same time that Linden Lab finishes its QA pass on the first-party viewer. During all this time, exploiters will presumably be sharing information about the exploit with other exploiters and exploring variations of the exploit to see if other flaws can be .. well, exploited by similar means. Most of the information actually in circulation among the users about (imagined) current exploits is largely incorrect - of the order of urban myths, and the penetration of knowledge of actual exploits and how to mitigate them (where that is possible) rarely spreads very far among the user-population. Paradoxically, security updates cause more anger and resentment than any other feeling. Actually, that brings me almost full circle. Let's assume that there is an exploit which can be mitigated by users, but is quite severe. (something of the order of the quicktime exploit for mitigation). Assume that this is fully disclosed when discovered. Roughly 65% of active users (which is a guess, but an educated one, so it's a pretty solid number) either won't become aware of it, or won't apply any mitigation (there are a number of factors involved there). Does that present a problem, if the majority of the users do nothing when exploit details become fully public? I think it does. From vector at leafpile.com Sat Dec 27 01:52:50 2008 From: vector at leafpile.com (Vector Hastings) Date: Sat Dec 27 01:52:57 2008 Subject: [sldev] Avatar mesh/morph exporter/importer Message-ID: Khyota, I share your excitement about this. I compiled the mesh_1_1_patchfile from http://jira.secondlife.com/browse/VWR-6199 with MSVS2008 Express against 1.21.6 and I've had the following experience: (FYI, my interest (as Mike knows) is mostly as a machinimator who wants to manipulate the facial expression morphs so they can be more useful as dramatic expressions.) Before I went to the trouble of modifying an emote mesh exported from this client, I decided to try and import it after export just to be sure I had everything working. So I went: Advanced>Character>Meshes & Morphs>headMesh>headMesh>Express_Embarassed_Emote>Save OBJ then I immediately loaded that same mesh using the same menu option: Advanced>Character>Meshes & Morphs>headMesh>headMesh>Express_Embarassed_Emote>Load OBJ I have two observations which are really questions I hope to resolve: 1. The new mesh seems to have "shrunk" my head. See the attached picture. 2. I was expecting it to replace the "emote" part of the avatar definition, so that when I get to the stage of modifying the meshes, I won't see the modified mesh unless I make my avi emote in a way that would have used a standard emote mesh. But in fact, it replaces the base head mesh. And it does so in a way that mostly negates the slider values for my head shape. I tried making my base head with 50's on all the sliders, thinking maybe it was a sizing issue (my avi has a big head :-) ). But that had no effect whatsoever, so I'm barking up the wrong tree. I tried to look at the source code changes from a previous patch for this, but there were some spacing changes and I couldn't create an automated diff-check (my skill here is very minimal). But it does look like there were some significant menu changes to perform LLM saves, and that might have destabilized an earlier version that might have been working better. >My guess with the texture baking is that the texture vertices changed. >Compare the two .obj files to see. I intend to add support for the face >information in the .obj file which ties the geometric vertices and >normals to the texture vertices, but for now, they have to be a one to >one correspondence in the correct order. You could try manually editing >the .obj files to use the new geometric vertices with the old texture >coordinates to see if that's the reason. A quick diff of the 2 files reveals that the ARE completely different, Quite new to modeling so im not sure how to keep them in the correct order. *wonders if anyone else is testing this with blender* Also importing the base mesh, seems to set it as the current mesh, instead of the base. Not sure if that was intended. I edited one of the vertex coordinates and it imported but i dont see a differance in the shape, but the texture baked correctly, ill play with that more later. >I deliberately chose to give the file picker the full path name, since I >thought it made sense to keep the .obj files with the .llm files. Is >the problem that you want to put them somewhere else and you have to >keep changing it for every save? Figured it would be the same as saving textures and snapshots :) not a big deal though. Khyota -------------- next part -------------- A non-text attachment was scrubbed... Name: StrangeSizing.jpg Type: image/jpeg Size: 283157 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081227/51463b25/StrangeSizing-0001.jpg From vector at leafpile.com Sat Dec 27 03:54:34 2008 From: vector at leafpile.com (Vector Hastings) Date: Sat Dec 27 03:54:28 2008 Subject: [sldev] Avatar mesh/morph exporter/importer Message-ID: Update on Mike's emote browser I've posted an earlier patch of Mike's to the Jira for this: http://jira.secondlife.com/browse/VWR-6199 . Mike will probably make this obsolete as soon as he sees this message, but for anyone else who might be working at strange times on this... It seems the original patch works the way he probably intended: I saved/loaded an emote, and my head didn't shrink or take on a permanent expression of embarrassment. ;-) Mike's later patch allows for saving in .llm format -- the native linden mesh format -- so it's a huge step forward. But right now using both the earlier and later patches may be useful for those who can compile the earlier patch. That's the only reason for this post -- to alert anyone interested in this to the availability of Mike's earlier functionality. Vector From GordonWendt at gmail.com Sat Dec 27 07:55:57 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sat Dec 27 07:56:00 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <4955CBBD.8030805@gmail.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <493033a70812262113x1fdfc7b8ma1e327836d61605@mail.gmail.com> <4955CBBD.8030805@gmail.com> Message-ID: <493033a70812270755o2b2fd777lf6b50dfc5b3f52a0@mail.gmail.com> Tateru, I think awareness in SL would be higher if LL wanted someone to know about an issue because they have the unique ability to notify most users (some viewers don't display that info) when the viewer loads, every user when they login and every logged in user at will. That can be done pre-patch to make people aware of mitigating factors. They also could pre-patch enforce that you had to take mitigating steps for example the quicktime patch where they enforced that you had to upgrade quicktime or turn quicktime off. They did this post patch but there's no reason the mitigation part of it couldn't be done pre patch I don't think, at least on viewers that weren't coded to ignore this check in which case it's caveat emptor anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081227/914e3586/attachment.htm From sldev at free.fr Sat Dec 27 11:44:39 2008 From: sldev at free.fr (Henri Beauchamp) Date: Sat Dec 27 11:44:49 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <104458.53743.qm@web63804.mail.re1.yahoo.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> Message-ID: <20081227204439.7e5d6f49.sldev@free.fr> On Fri, 26 Dec 2008 19:16:47 -0800 (PST), Boy Lane wrote: > > so... this is just a long winded discussion to support the following > > statement: > > > > "telling everybody about a security vulnerability before remediation is > > available is bad." > > And this is simply wrong. Not only wrong but unacceptable. > > We don't need to go through a long list of historical events or personal > experiences. Let's just keep it down to the facts. > > LL decided to put the SecondLife code into?open source, available for > everyone everywhere.?As such any approach of security through obscurity > is doomed to fail. It is not as much as ensuring "security via obscurity", than to avoid giving to script kiddies, wannabe hackers and griefers an easy recipe for hacking SL before the vulnerability is plugged. > .../... > I'd expect LL to provide regular security bulletins in an organized way, > accessible to all users who?would be interested in them. That does not > mean a detailed?piece of code,?but a clear description of the >?vulnerability and?the risk. Mind you, a very large number of Open Source project (I could cite the Linux kernel itself !) sometimes do delay the publication of a vulnerability so to prevent major security risks. Describing what feature is flawed is just a pointer to where to lok at in the code, so even if you don't give a piece of code as a proof of concept to demonstrate how someone could exploit a vulnerability, you still give directions to hackers as to where to search. Admitedly, this would only permit to true hackers to find out a proper exploit, but it is still a big risk to take. > A good distribution list?reaching dedicated people would indeed be > the SLDev mailing list. So that developers can decide?what to do, > perhaps help to fix it in faster way than LL would be able to or > is unwilling to do, or if this is not possible to provide > recommendations such as not to use a particular version of the viewer. Depending on the vulnerability and what risk it involves, this list is indeed good enough. Even the SL grid status blog could do... Examples: 1.- A vulnerability is discovered in the viewer that allows people to crash it via a particular set of parameters (in a prim, a media, etc). There is no big risk here, but for "standard" griefing which can easily be dealt with or worked around (by muting the griefer for example). In this case, the vulnerability and the work around should be made public on the grid status blog so that everyone is aware of it and knows what to do should the vulnerability hit them before a definitive fix is published. 2.- A vulnerability is discovered that would allow a clever hacker using their own hacked simulator (on an OpenSim grid) to rob money to people visiting their sim. The risk higher, here, and it is best to restrict the audience of people who will be aware of how to exploit the vulnerability. Publishing the details on the sldev list would be fine, and a warning shall also be published on the SL and OpenSim blogs to warn people and ask them to avoid connecting to OpenSim servers they don't trust till a new version of the viewer is published. 3.- A vulnerability is discovered internally by LL that would allow to steal money on the SL grid via a particular set of parameters (in a prim, a media, etc). This is a very high risk vulnerability (it does not even involve hacking a server, but only providing a crafted asset in a standard sim), and it is likely that only LL is aware of it so far. I do think such a vulnerability shall *not* be disclosed until a proper fix id found, possibly associating trusted third parties developpers. Once the fix is found, all the developpers of the third parties viewers should recieve the patch and some time should be left for them to publish updated versions of their viewers, time during which LL would publish their own official version. Only then, should the vulnerability be disclosed to the public. > I remember that last security disaster in the 1.20.17 version. LL > decided to work behind closed doors.?Even though a fix was internally > available it was not provided in source / patch form to 3rd party > developers, This is not entirely true... LL did indeed not tell anyone about the vulnerability until they had fixed it, but then the updated code was provided to third parties developpers. Admitedly, this latter part could have been optimized and this is exactly what Rob proposed with the dedicated vulnerability list. > leaving 10's?if not 100's of thousand users vulnerable. Partially true: but till a fix is found, anyone is vulnerable anyway. Not disclosing the vulnerability at least prevented script kiddies and wannabe hackers to exploit it... so, I personally thing it was the right thing to do. > It was only made available several days later through?obscure > channels to a handful of developers who asked for. Here again, not entirely true: an announce was publiches on this list, asking to third parties developpers to contact Rob. Admitedly, this was not the fastest and easiest of the processes, thus the interest of a list. > And it was half hearted as LL decided not to backport the security > patches to the 1.19 pre-windlight viewers but left that task > completely to?the developers of alternative viewers. Yes, I did the backport to v1.19. But although I regret (and tell it on every occasion, like now) that LL does not maintain a viewer with the legacy renderer any more (thus letting people with 3 years old computers without a usable and resonably fast viewer for their machine), I cannot blame them for not providing a fix to a discontinued branch of the viewer... Take Firefox... v1 has been discontinued even though it's the only version that can run reasonnably fast on old, i586 computers (thanks to GTK+ v1 which is much less bloated than v2 and runs twice or thrice faster). Firefox v2 will soon be discontinued too... there are no security fix for discontinued Firefox branches: that's life... > The only way to mitigate the risk was to tell people not to use in > our case the Cool Viewer as the vulnerability and risks were?unknown. The Linux version of the Cool SL Viewer (both v1.19 and v1.20) was fixed within 24 hours of the release of the official LL viewer... Not that dramatic, but a dedicated mailing list would definitely help reducing such delays down to 0. So, to summarize, I'll just say that: There is no simple rule as to whether or not all vulnerabilities shall be disclosed. It all depends on how severe is the vulnerability, on who discovered it, and whether there is an existing work around or not. If the vulnerability is severe, *and* was discovered internally by LL *and* has no work around, then it is definitely safer for everyone to fix it internally, publish the patch only to third parties vewiers makers, and only after everything is pluged, tell everyone else about it and ask them to update immediately. Henri. From vector at leafpile.com Sat Dec 27 14:34:04 2008 From: vector at leafpile.com (Vector Hastings) Date: Sat Dec 27 14:34:04 2008 Subject: [sldev] Avatar mesh/morph exporter/importer Message-ID: Khyota wrote: "*wonders if anyone else is testing this with blender* " I'm attaching screenshots for how to import/export .obj into blender and have it work in Mike's mesh1.0 browser. I still can't get it to work in mesh1.1, but I haven't looked at the code. Mike'll probably fix it soon. Basically, the critical thing is to turn off all the options under Export: Edges, Materials and UVs. They must be adding information to the vertices that makes for bad behavior when imported into the viewer. If these screenshots don't appear, they're also uploaded to the jira: http://jira.secondlife.com/browse/VWR-6199 -------------- next part -------------- A non-text attachment was scrubbed... Name: BlenderExportSettings.jpg Type: image/jpeg Size: 54433 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081227/9bb54432/BlenderExportSettings-0001.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: BlenderImportSettings.jpg Type: image/jpeg Size: 43361 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081227/9bb54432/BlenderImportSettings-0001.jpg From infinity at lindenlab.com Sun Dec 28 07:01:58 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Sun Dec 28 07:02:01 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <4955CBBD.8030805@gmail.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <493033a70812262113x1fdfc7b8ma1e327836d61605@mail.gmail.com> <4955CBBD.8030805@gmail.com> Message-ID: hmm.. i think i see a disconnect here. not all vulnerabilities are discovered by a community that exploits them. some are discovered internally, others are discovered by people "close" to the lab who's personal interests are not served by exploit. and i think your comment encapsulates issues with fair and early disclosure: "vulnerabilities should be fixed as soon as possible after discovery and the discoverer should limit disclosure to those parties who can effectively reduce the risk of exploit." so, agreed: fixing a security bug includes sending it through the QA process. and: if there is a large community of persons exploiting the bug, then the risk of disclosure to the group of 3rd party developers working on SL projects is reduced. but: if the bug is not being exploited, then you increase the risk of exploit by disclosing the bug before a patch can be produced. -cheers -infinity On Dec 26, 2008, at 10:31 PM, Tateru Nino wrote: > Somewhere around the time this last QA phase begins, I'm guessing is > when it is proposed that the third-parties on the disclosure list get > notified, which would have their own viewers ready around the same > time > that Linden Lab finishes its QA pass on the first-party viewer. > > During all this time, exploiters will presumably be sharing > information > about the exploit with other exploiters and exploring variations of > the > exploit to see if other flaws can be .. well, exploited by similar > means. From infinity at lindenlab.com Sun Dec 28 07:10:56 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Sun Dec 28 07:11:00 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> Message-ID: <857F2646-FBF0-430E-8BBC-740C55258702@lindenlab.com> what are users going to use to patch their viewers? remember. the vast majority of SL users do not compile the viewer from source, they download it from the SL website. On Dec 26, 2008, at 3:44 PM, ordinal.malaprop@fastmail.fm wrote: > > On 26 Dec 2008, at 17:01, infinity@lindenlab.com wrote: > >> so.. for the sake of discussion.. let's assume the following >> discussion is >> true "there is a serious exploit in the current LL viewer code >> which will >> lead to disclosure of sensitive user information, compromise of >> systems >> running the client, illegal asset or funds transfer and global >> thermonuclear war." >> >> if a security researcher out in the trenches discovers a >> vulnerability, >> disclosing it widely before a fix is available is clearly bad for >> not only >> Linden, but for the user community. nuclear war is generally bad for >> everybody... >> >> ..."telling everybody about a security vulnerability before >> remediation is >> available is bad." > > I am sorry but I'm afraid that that really doesn't make the case at > all. Your post ignores any potential benefit granted to users by > knowing what an exploit is and how to counteract it before it is > once-and-for-all fixed on the server side by LL. The overall impact > is still better if users have the chance to patch and adapt before > fixes are available if fixes don't arrive almost immediately. Which > they may well not do. From infinity at lindenlab.com Sun Dec 28 07:23:16 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Sun Dec 28 07:23:20 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <20081227204439.7e5d6f49.sldev@free.fr> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> <20081227204439.7e5d6f49.sldev@free.fr> Message-ID: thx, henri... i think you understand what i'm trying to communicate. but... let me take a stab at trying to recapitulate boy lane's concerns: "LL discovering a vulnerability in the viewer code and not disclosing to people who enhance the SL community by building on top of the viewer is irritating and possibly immoral." because... it puts LL in the position of being able to produce a vulnerability free viewer, disclose the vulnerability and then have the rest of the community scrambling to try to fix their products. or maybe it's the... information wants to be free / there should be no asymmetric information concept. so.. getting back to Rob's original post... "do you think it's acceptable for Linden to REQUIRE members of the 3rd party viewer community to sign a non-disclosure agreement as a precondition of receiving early disclosure notices?" and if not, why? On Dec 27, 2008, at 11:44 AM, Henri Beauchamp wrote: > On Fri, 26 Dec 2008 19:16:47 -0800 (PST), Boy Lane wrote: > >>> so... this is just a long winded discussion to support the following >>> statement: >>> >>> "telling everybody about a security vulnerability before >>> remediation is >>> available is bad." >> >> And this is simply wrong. Not only wrong but unacceptable. >> >> We don't need to go through a long list of historical events or >> personal >> experiences. Let's just keep it down to the facts. >> >> LL decided to put the SecondLife code into open source, available for >> everyone everywhere. As such any approach of security through >> obscurity >> is doomed to fail. > > It is not as much as ensuring "security via obscurity", than to avoid > giving to script kiddies, wannabe hackers and griefers an easy recipe > for hacking SL before the vulnerability is plugged. > >> .../... >> I'd expect LL to provide regular security bulletins in an organized >> way, >> accessible to all users who would be interested in them. That does >> not >> mean a detailed piece of code, but a clear description of the >> vulnerability and the risk. > > Mind you, a very large number of Open Source project (I could cite the > Linux kernel itself !) sometimes do delay the publication of a > vulnerability so to prevent major security risks. Describing what > feature is flawed is just a pointer to where to lok at in the code, > so even if you don't give a piece of code as a proof of concept to > demonstrate how someone could exploit a vulnerability, you still > give directions to hackers as to where to search. Admitedly, this > would only permit to true hackers to find out a proper exploit, > but it is still a big risk to take. > >> A good distribution list reaching dedicated people would indeed be >> the SLDev mailing list. So that developers can decide what to do, >> perhaps help to fix it in faster way than LL would be able to or >> is unwilling to do, or if this is not possible to provide >> recommendations such as not to use a particular version of the >> viewer. > > Depending on the vulnerability and what risk it involves, this list > is indeed good enough. Even the SL grid status blog could do... > > Examples: > > 1.- A vulnerability is discovered in the viewer that allows people > to crash it via a particular set of parameters (in a prim, a media, > etc). > > There is no big risk here, but for "standard" griefing which can > easily be dealt with or worked around (by muting the griefer for > example). > > In this case, the vulnerability and the work around should be made > public on the grid status blog so that everyone is aware of it > and knows what to do should the vulnerability hit them before a > definitive fix is published. > > 2.- A vulnerability is discovered that would allow a clever hacker > using their own hacked simulator (on an OpenSim grid) to rob money > to people visiting their sim. > > The risk higher, here, and it is best to restrict the audience of > people who will be aware of how to exploit the vulnerability. > Publishing the details on the sldev list would be fine, and a > warning shall also be published on the SL and OpenSim blogs to > warn people and ask them to avoid connecting to OpenSim servers > they don't trust till a new version of the viewer is published. > > 3.- A vulnerability is discovered internally by LL that would allow > to steal money on the SL grid via a particular set of parameters > (in a prim, a media, etc). > > This is a very high risk vulnerability (it does not even involve > hacking a server, but only providing a crafted asset in a standard > sim), and it is likely that only LL is aware of it so far. > > I do think such a vulnerability shall *not* be disclosed until > a proper fix id found, possibly associating trusted third parties > developpers. > Once the fix is found, all the developpers of the third parties > viewers should recieve the patch and some time should be left for > them to publish updated versions of their viewers, time during which > LL would publish their own official version. > Only then, should the vulnerability be disclosed to the public. > >> I remember that last security disaster in the 1.20.17 version. LL >> decided to work behind closed doors. Even though a fix was internally >> available it was not provided in source / patch form to 3rd party >> developers, > This is not entirely true... LL did indeed not tell anyone about > the vulnerability until they had fixed it, but then the updated code > was provided to third parties developpers. Admitedly, this latter > part could have been optimized and this is exactly what Rob proposed > with the dedicated vulnerability list. > >> leaving 10's if not 100's of thousand users vulnerable. > > Partially true: but till a fix is found, anyone is vulnerable anyway. > Not disclosing the vulnerability at least prevented script kiddies > and wannabe hackers to exploit it... so, I personally thing it was > the right thing to do. > >> It was only made available several days later through obscure >> channels to a handful of developers who asked for. > > Here again, not entirely true: an announce was publiches on this > list, asking to third parties developpers to contact Rob. > Admitedly, this was not the fastest and easiest of the processes, > thus the interest of a list. > >> And it was half hearted as LL decided not to backport the security >> patches to the 1.19 pre-windlight viewers but left that task >> completely to the developers of alternative viewers. > > Yes, I did the backport to v1.19. But although I regret (and tell > it on every occasion, like now) that LL does not maintain a viewer > with the legacy renderer any more (thus letting people with 3 years > old computers without a usable and resonably fast viewer for their > machine), I cannot blame them for not providing a fix to a > discontinued branch of the viewer... > Take Firefox... v1 has been discontinued even though it's the only > version that can run reasonnably fast on old, i586 computers (thanks > to GTK+ v1 which is much less bloated than v2 and runs twice or thrice > faster). Firefox v2 will soon be discontinued too... there are no > security fix for discontinued Firefox branches: that's life... > >> The only way to mitigate the risk was to tell people not to use in >> our case the Cool Viewer as the vulnerability and risks were unknown. > > The Linux version of the Cool SL Viewer (both v1.19 and v1.20) was > fixed within 24 hours of the release of the official LL viewer... > Not that dramatic, but a dedicated mailing list would definitely help > reducing such delays down to 0. > > > So, to summarize, I'll just say that: > > There is no simple rule as to whether or not all vulnerabilities > shall be disclosed. It all depends on how severe is the vulnerability, > on who discovered it, and whether there is an existing work around or > not. > > If the vulnerability is severe, *and* was discovered internally by LL > *and* has no work around, then it is definitely safer for everyone to > fix it internally, publish the patch only to third parties vewiers > makers, and only after everything is pluged, tell everyone else about > it and ask them to update immediately. > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From TammyNowotny at mac.com Sun Dec 28 08:03:17 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Sun Dec 28 08:03:21 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> <20081227204439.7e5d6f49.sldev@free.fr> Message-ID: <4957A345.70508@mac.com> Meadhbh Hamrick (Infinity) wrote: > > so.. getting back to Rob's original post... > > "do you think it's acceptable for Linden to REQUIRE members of the 3rd > party viewer community to sign a non-disclosure agreement as a > precondition of receiving early disclosure notices?" > > and if not, why? My L$5 on that: I think it's acceptable. There are all sorts of good reasons why LL might want to tell the developers certain things they aren't ready to tell the whole world, although in general it is best not to keep more secrets than you absolutely have to. As for how users can patch their viewers, well--- if the user is on an operating system released during the current century, then software developers should be able to semi-automatically push updates to the user community. (That's what Linden Lab does.) If users are on an older OS, they can be urged to visit a website, or the developer can even email update notices to registered users. Henri said: > >> >> Take Firefox... v1 has been discontinued even though it's the only >> version that can run reasonnably fast on old, i586 computers (thanks >> to GTK+ v1 which is much less bloated than v2 and runs twice or thrice >> faster). Firefox v2 will soon be discontinued too... there are no >> security fix for discontinued Firefox branches: that's life... >> Mozilla.org actually did release an update to FireFox 2.0 recently. In the case of FireFox, it's not just FireFox which is open source; the basic Mozilla browser standard is itself open source. FireFox can't be all things to all people, and there might come a point where it would be better to build a whole new Mozilla browser from the ground up for legacy hardware rather than to keep patching the original v1 FireFox browser. > From tateru.nino at gmail.com Sun Dec 28 08:10:13 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Dec 28 08:10:19 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> <20081227204439.7e5d6f49.sldev@free.fr> Message-ID: <4957A4E5.2070204@weblogsinc.com> I'd like to know what benefits the non-disclosure agreements provide. The lab has a history of not enforcing them, so I'm a bit vague on who benefits from there being NDAs in this circuit and in quite what way, exactly. Could you expand on that a little more? Meadhbh Hamrick (Infinity) wrote: > thx, henri... i think you understand what i'm trying to communicate. > > but... let me take a stab at trying to recapitulate boy lane's concerns: > > "LL discovering a vulnerability in the viewer code and not disclosing > to people who enhance the SL community by building on top of the > viewer is irritating and possibly immoral." > > because... it puts LL in the position of being able to produce a > vulnerability free viewer, disclose the vulnerability and then have > the rest of the community scrambling to try to fix their products. > > or maybe it's the... information wants to be free / there should be no > asymmetric information concept. > > so.. getting back to Rob's original post... > > "do you think it's acceptable for Linden to REQUIRE members of the 3rd > party viewer community to sign a non-disclosure agreement as a > precondition of receiving early disclosure notices?" > > and if not, why? > > On Dec 27, 2008, at 11:44 AM, Henri Beauchamp wrote: > >> On Fri, 26 Dec 2008 19:16:47 -0800 (PST), Boy Lane wrote: >> >>>> so... this is just a long winded discussion to support the following >>>> statement: >>>> >>>> "telling everybody about a security vulnerability before >>>> remediation is >>>> available is bad." >>> >>> And this is simply wrong. Not only wrong but unacceptable. >>> >>> We don't need to go through a long list of historical events or >>> personal >>> experiences. Let's just keep it down to the facts. >>> >>> LL decided to put the SecondLife code into open source, available for >>> everyone everywhere. As such any approach of security through obscurity >>> is doomed to fail. >> >> It is not as much as ensuring "security via obscurity", than to avoid >> giving to script kiddies, wannabe hackers and griefers an easy recipe >> for hacking SL before the vulnerability is plugged. >> >>> .../... >>> I'd expect LL to provide regular security bulletins in an organized >>> way, >>> accessible to all users who would be interested in them. That does not >>> mean a detailed piece of code, but a clear description of the >>> vulnerability and the risk. >> >> Mind you, a very large number of Open Source project (I could cite the >> Linux kernel itself !) sometimes do delay the publication of a >> vulnerability so to prevent major security risks. Describing what >> feature is flawed is just a pointer to where to lok at in the code, >> so even if you don't give a piece of code as a proof of concept to >> demonstrate how someone could exploit a vulnerability, you still >> give directions to hackers as to where to search. Admitedly, this >> would only permit to true hackers to find out a proper exploit, >> but it is still a big risk to take. >> >>> A good distribution list reaching dedicated people would indeed be >>> the SLDev mailing list. So that developers can decide what to do, >>> perhaps help to fix it in faster way than LL would be able to or >>> is unwilling to do, or if this is not possible to provide >>> recommendations such as not to use a particular version of the viewer. >> >> Depending on the vulnerability and what risk it involves, this list >> is indeed good enough. Even the SL grid status blog could do... >> >> Examples: >> >> 1.- A vulnerability is discovered in the viewer that allows people >> to crash it via a particular set of parameters (in a prim, a media, >> etc). >> >> There is no big risk here, but for "standard" griefing which can >> easily be dealt with or worked around (by muting the griefer for >> example). >> >> In this case, the vulnerability and the work around should be made >> public on the grid status blog so that everyone is aware of it >> and knows what to do should the vulnerability hit them before a >> definitive fix is published. >> >> 2.- A vulnerability is discovered that would allow a clever hacker >> using their own hacked simulator (on an OpenSim grid) to rob money >> to people visiting their sim. >> >> The risk higher, here, and it is best to restrict the audience of >> people who will be aware of how to exploit the vulnerability. >> Publishing the details on the sldev list would be fine, and a >> warning shall also be published on the SL and OpenSim blogs to >> warn people and ask them to avoid connecting to OpenSim servers >> they don't trust till a new version of the viewer is published. >> >> 3.- A vulnerability is discovered internally by LL that would allow >> to steal money on the SL grid via a particular set of parameters >> (in a prim, a media, etc). >> >> This is a very high risk vulnerability (it does not even involve >> hacking a server, but only providing a crafted asset in a standard >> sim), and it is likely that only LL is aware of it so far. >> >> I do think such a vulnerability shall *not* be disclosed until >> a proper fix id found, possibly associating trusted third parties >> developpers. >> Once the fix is found, all the developpers of the third parties >> viewers should recieve the patch and some time should be left for >> them to publish updated versions of their viewers, time during which >> LL would publish their own official version. >> Only then, should the vulnerability be disclosed to the public. >> >>> I remember that last security disaster in the 1.20.17 version. LL >>> decided to work behind closed doors. Even though a fix was internally >>> available it was not provided in source / patch form to 3rd party >>> developers, >> This is not entirely true... LL did indeed not tell anyone about >> the vulnerability until they had fixed it, but then the updated code >> was provided to third parties developpers. Admitedly, this latter >> part could have been optimized and this is exactly what Rob proposed >> with the dedicated vulnerability list. >> >>> leaving 10's if not 100's of thousand users vulnerable. >> >> Partially true: but till a fix is found, anyone is vulnerable anyway. >> Not disclosing the vulnerability at least prevented script kiddies >> and wannabe hackers to exploit it... so, I personally thing it was >> the right thing to do. >> >>> It was only made available several days later through obscure >>> channels to a handful of developers who asked for. >> >> Here again, not entirely true: an announce was publiches on this >> list, asking to third parties developpers to contact Rob. >> Admitedly, this was not the fastest and easiest of the processes, >> thus the interest of a list. >> >>> And it was half hearted as LL decided not to backport the security >>> patches to the 1.19 pre-windlight viewers but left that task >>> completely to the developers of alternative viewers. >> >> Yes, I did the backport to v1.19. But although I regret (and tell >> it on every occasion, like now) that LL does not maintain a viewer >> with the legacy renderer any more (thus letting people with 3 years >> old computers without a usable and resonably fast viewer for their >> machine), I cannot blame them for not providing a fix to a >> discontinued branch of the viewer... >> Take Firefox... v1 has been discontinued even though it's the only >> version that can run reasonnably fast on old, i586 computers (thanks >> to GTK+ v1 which is much less bloated than v2 and runs twice or thrice >> faster). Firefox v2 will soon be discontinued too... there are no >> security fix for discontinued Firefox branches: that's life... >> >>> The only way to mitigate the risk was to tell people not to use in >>> our case the Cool Viewer as the vulnerability and risks were unknown. >> >> The Linux version of the Cool SL Viewer (both v1.19 and v1.20) was >> fixed within 24 hours of the release of the official LL viewer... >> Not that dramatic, but a dedicated mailing list would definitely help >> reducing such delays down to 0. >> >> >> So, to summarize, I'll just say that: >> >> There is no simple rule as to whether or not all vulnerabilities >> shall be disclosed. It all depends on how severe is the vulnerability, >> on who discovered it, and whether there is an existing work around or >> not. >> >> If the vulnerability is severe, *and* was discovered internally by LL >> *and* has no work around, then it is definitely safer for everyone to >> fix it internally, publish the patch only to third parties vewiers >> makers, and only after everything is pluged, tell everyone else about >> it and ask them to update immediately. >> >> Henri. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Tateru Nino http://www.massively.com/ From infinity at lindenlab.com Sun Dec 28 10:37:49 2008 From: infinity at lindenlab.com (Meadhbh Hamrick (Infinity)) Date: Sun Dec 28 10:37:53 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <4957A4E5.2070204@weblogsinc.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> <20081227204439.7e5d6f49.sldev@free.fr> <4957A4E5.2070204@weblogsinc.com> Message-ID: like all things managed by contract, it is not the contract that is important, but the reasonable expectation of both party's behaviors. when Linden discovers a vulnerability in our software that is not being exploited, we're not in a hurry to alert the constellation of exploit generators out on the fringes of the net. Well... at least not until we have a working fix. this may be upsetting to some people, but we have a non-insignificant obligation to our community to do what we can to prevent fraud, asset theft and abuse, and part of our behavior in support of this obligation is we don't tell the "bad guys" about vulnerabilities until a patch has been applied. unfortunately, it is very difficult to tell who is a "good guy" and who is a "bad guy." we currently resolve this issue by not telling anyone outside the lab. but for reasons previously mentioned, this can be irritating to the community of 3rd party software developers we are trying to support and encourage. the NDA would provide a legal framework describing action we would take should a 3rd party software developer disclose information deemed to be sensitive. in short, it's the paper that tells you, the third party developer, that if we tell you that you can do something bad by manipulating the right packets in and out of the system, and you tell "bad guys" or people who will tell "bad guys", we're at least going to stop telling you about new vulnerabilities we discover. there may be a different process for vulnerabilities that are already widely publicized. there may be a different process for vulnerabilities discovered by a 3rd party. i think this process is in keeping with industry best practices. -cheers -infinity On Dec 28, 2008, at 8:10 AM, Tateru Nino wrote: > I'd like to know what benefits the non-disclosure agreements provide. > The lab has a history of not enforcing them, so I'm a bit vague on who > benefits from there being NDAs in this circuit and in quite what way, > exactly. Could you expand on that a little more? > > Meadhbh Hamrick (Infinity) wrote: >> thx, henri... i think you understand what i'm trying to communicate. >> >> but... let me take a stab at trying to recapitulate boy lane's >> concerns: >> >> "LL discovering a vulnerability in the viewer code and not disclosing >> to people who enhance the SL community by building on top of the >> viewer is irritating and possibly immoral." >> >> because... it puts LL in the position of being able to produce a >> vulnerability free viewer, disclose the vulnerability and then have >> the rest of the community scrambling to try to fix their products. >> >> or maybe it's the... information wants to be free / there should be >> no >> asymmetric information concept. >> >> so.. getting back to Rob's original post... >> >> "do you think it's acceptable for Linden to REQUIRE members of the >> 3rd >> party viewer community to sign a non-disclosure agreement as a >> precondition of receiving early disclosure notices?" >> >> and if not, why? >> >> On Dec 27, 2008, at 11:44 AM, Henri Beauchamp wrote: >> >>> On Fri, 26 Dec 2008 19:16:47 -0800 (PST), Boy Lane wrote: >>> >>>>> so... this is just a long winded discussion to support the >>>>> following >>>>> statement: >>>>> >>>>> "telling everybody about a security vulnerability before >>>>> remediation is >>>>> available is bad." >>>> >>>> And this is simply wrong. Not only wrong but unacceptable. >>>> >>>> We don't need to go through a long list of historical events or >>>> personal >>>> experiences. Let's just keep it down to the facts. >>>> >>>> LL decided to put the SecondLife code into open source, available >>>> for >>>> everyone everywhere. As such any approach of security through >>>> obscurity >>>> is doomed to fail. >>> >>> It is not as much as ensuring "security via obscurity", than to >>> avoid >>> giving to script kiddies, wannabe hackers and griefers an easy >>> recipe >>> for hacking SL before the vulnerability is plugged. >>> >>>> .../... >>>> I'd expect LL to provide regular security bulletins in an organized >>>> way, >>>> accessible to all users who would be interested in them. That >>>> does not >>>> mean a detailed piece of code, but a clear description of the >>>> vulnerability and the risk. >>> >>> Mind you, a very large number of Open Source project (I could cite >>> the >>> Linux kernel itself !) sometimes do delay the publication of a >>> vulnerability so to prevent major security risks. Describing what >>> feature is flawed is just a pointer to where to lok at in the code, >>> so even if you don't give a piece of code as a proof of concept to >>> demonstrate how someone could exploit a vulnerability, you still >>> give directions to hackers as to where to search. Admitedly, this >>> would only permit to true hackers to find out a proper exploit, >>> but it is still a big risk to take. >>> >>>> A good distribution list reaching dedicated people would indeed be >>>> the SLDev mailing list. So that developers can decide what to do, >>>> perhaps help to fix it in faster way than LL would be able to or >>>> is unwilling to do, or if this is not possible to provide >>>> recommendations such as not to use a particular version of the >>>> viewer. >>> >>> Depending on the vulnerability and what risk it involves, this list >>> is indeed good enough. Even the SL grid status blog could do... >>> >>> Examples: >>> >>> 1.- A vulnerability is discovered in the viewer that allows people >>> to crash it via a particular set of parameters (in a prim, a media, >>> etc). >>> >>> There is no big risk here, but for "standard" griefing which can >>> easily be dealt with or worked around (by muting the griefer for >>> example). >>> >>> In this case, the vulnerability and the work around should be made >>> public on the grid status blog so that everyone is aware of it >>> and knows what to do should the vulnerability hit them before a >>> definitive fix is published. >>> >>> 2.- A vulnerability is discovered that would allow a clever hacker >>> using their own hacked simulator (on an OpenSim grid) to rob money >>> to people visiting their sim. >>> >>> The risk higher, here, and it is best to restrict the audience of >>> people who will be aware of how to exploit the vulnerability. >>> Publishing the details on the sldev list would be fine, and a >>> warning shall also be published on the SL and OpenSim blogs to >>> warn people and ask them to avoid connecting to OpenSim servers >>> they don't trust till a new version of the viewer is published. >>> >>> 3.- A vulnerability is discovered internally by LL that would allow >>> to steal money on the SL grid via a particular set of parameters >>> (in a prim, a media, etc). >>> >>> This is a very high risk vulnerability (it does not even involve >>> hacking a server, but only providing a crafted asset in a standard >>> sim), and it is likely that only LL is aware of it so far. >>> >>> I do think such a vulnerability shall *not* be disclosed until >>> a proper fix id found, possibly associating trusted third parties >>> developpers. >>> Once the fix is found, all the developpers of the third parties >>> viewers should recieve the patch and some time should be left for >>> them to publish updated versions of their viewers, time during which >>> LL would publish their own official version. >>> Only then, should the vulnerability be disclosed to the public. >>> >>>> I remember that last security disaster in the 1.20.17 version. LL >>>> decided to work behind closed doors. Even though a fix was >>>> internally >>>> available it was not provided in source / patch form to 3rd party >>>> developers, >>> This is not entirely true... LL did indeed not tell anyone about >>> the vulnerability until they had fixed it, but then the updated code >>> was provided to third parties developpers. Admitedly, this latter >>> part could have been optimized and this is exactly what Rob proposed >>> with the dedicated vulnerability list. >>> >>>> leaving 10's if not 100's of thousand users vulnerable. >>> >>> Partially true: but till a fix is found, anyone is vulnerable >>> anyway. >>> Not disclosing the vulnerability at least prevented script kiddies >>> and wannabe hackers to exploit it... so, I personally thing it was >>> the right thing to do. >>> >>>> It was only made available several days later through obscure >>>> channels to a handful of developers who asked for. >>> >>> Here again, not entirely true: an announce was publiches on this >>> list, asking to third parties developpers to contact Rob. >>> Admitedly, this was not the fastest and easiest of the processes, >>> thus the interest of a list. >>> >>>> And it was half hearted as LL decided not to backport the security >>>> patches to the 1.19 pre-windlight viewers but left that task >>>> completely to the developers of alternative viewers. >>> >>> Yes, I did the backport to v1.19. But although I regret (and tell >>> it on every occasion, like now) that LL does not maintain a viewer >>> with the legacy renderer any more (thus letting people with 3 years >>> old computers without a usable and resonably fast viewer for their >>> machine), I cannot blame them for not providing a fix to a >>> discontinued branch of the viewer... >>> Take Firefox... v1 has been discontinued even though it's the only >>> version that can run reasonnably fast on old, i586 computers (thanks >>> to GTK+ v1 which is much less bloated than v2 and runs twice or >>> thrice >>> faster). Firefox v2 will soon be discontinued too... there are no >>> security fix for discontinued Firefox branches: that's life... >>> >>>> The only way to mitigate the risk was to tell people not to use in >>>> our case the Cool Viewer as the vulnerability and risks were >>>> unknown. >>> >>> The Linux version of the Cool SL Viewer (both v1.19 and v1.20) was >>> fixed within 24 hours of the release of the official LL viewer... >>> Not that dramatic, but a dedicated mailing list would definitely >>> help >>> reducing such delays down to 0. >>> >>> >>> So, to summarize, I'll just say that: >>> >>> There is no simple rule as to whether or not all vulnerabilities >>> shall be disclosed. It all depends on how severe is the >>> vulnerability, >>> on who discovered it, and whether there is an existing work around >>> or >>> not. >>> >>> If the vulnerability is severe, *and* was discovered internally by >>> LL >>> *and* has no work around, then it is definitely safer for everyone >>> to >>> fix it internally, publish the patch only to third parties vewiers >>> makers, and only after everything is pluged, tell everyone else >>> about >>> it and ask them to update immediately. >>> >>> Henri. >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -- > Tateru Nino > http://www.massively.com/ > From tateru.nino at gmail.com Sun Dec 28 21:27:05 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Dec 28 21:27:11 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> <20081227204439.7e5d6f49.sldev@free.fr> <4957A4E5.2070204@weblogsinc.com> Message-ID: <49585FA9.8030505@gmail.com> Fair enough, but what *are* those actions. The question is: "do you think it's acceptable for Linden to REQUIRE members of the 3rd party viewer community to sign a non-disclosure agreement as a precondition of receiving early disclosure notices?" Is it acceptable? That would depend on entirely what the agreement actually *says*, wouldn't it? It's a pig-in-a-poke situation. I'd be hesitant to say either yes or no in answer to the question without knowing what the requirements, protections and remedies for both parties are. I mean, the idea may be fine in principle, but the document itself might turn out to be unacceptable. (Or maybe some might view it the other way around) Meadhbh Hamrick (Infinity) wrote: > like all things managed by contract, it is not the contract that is > important, but the reasonable expectation of both party's behaviors. > > when Linden discovers a vulnerability in our software that is not > being exploited, we're not in a hurry to alert the constellation of > exploit generators out on the fringes of the net. Well... at least not > until we have a working fix. > > this may be upsetting to some people, but we have a non-insignificant > obligation to our community to do what we can to prevent fraud, asset > theft and abuse, and part of our behavior in support of this > obligation is we don't tell the "bad guys" about vulnerabilities until > a patch has been applied. unfortunately, it is very difficult to tell > who is a "good guy" and who is a "bad guy." we currently resolve this > issue by not telling anyone outside the lab. > > but > > for reasons previously mentioned, this can be irritating to the > community of 3rd party software developers we are trying to support > and encourage. the NDA would provide a legal framework describing > action we would take should a 3rd party software developer disclose > information deemed to be sensitive. > > in short, it's the paper that tells you, the third party developer, > that if we tell you that you can do something bad by manipulating the > right packets in and out of the system, and you tell "bad guys" or > people who will tell "bad guys", we're at least going to stop telling > you about new vulnerabilities we discover. > > there may be a different process for vulnerabilities that are already > widely publicized. > > there may be a different process for vulnerabilities discovered by a > 3rd party. > > i think this process is in keeping with industry best practices. > > -cheers > -infinity > > On Dec 28, 2008, at 8:10 AM, Tateru Nino wrote: > >> I'd like to know what benefits the non-disclosure agreements provide. >> The lab has a history of not enforcing them, so I'm a bit vague on who >> benefits from there being NDAs in this circuit and in quite what way, >> exactly. Could you expand on that a little more? >> >> Meadhbh Hamrick (Infinity) wrote: >>> thx, henri... i think you understand what i'm trying to communicate. >>> >>> but... let me take a stab at trying to recapitulate boy lane's >>> concerns: >>> >>> "LL discovering a vulnerability in the viewer code and not disclosing >>> to people who enhance the SL community by building on top of the >>> viewer is irritating and possibly immoral." >>> >>> because... it puts LL in the position of being able to produce a >>> vulnerability free viewer, disclose the vulnerability and then have >>> the rest of the community scrambling to try to fix their products. >>> >>> or maybe it's the... information wants to be free / there should be no >>> asymmetric information concept. >>> >>> so.. getting back to Rob's original post... >>> >>> "do you think it's acceptable for Linden to REQUIRE members of the 3rd >>> party viewer community to sign a non-disclosure agreement as a >>> precondition of receiving early disclosure notices?" >>> >>> and if not, why? >>> >>> On Dec 27, 2008, at 11:44 AM, Henri Beauchamp wrote: >>> >>>> On Fri, 26 Dec 2008 19:16:47 -0800 (PST), Boy Lane wrote: >>>> >>>>>> so... this is just a long winded discussion to support the following >>>>>> statement: >>>>>> >>>>>> "telling everybody about a security vulnerability before >>>>>> remediation is >>>>>> available is bad." >>>>> >>>>> And this is simply wrong. Not only wrong but unacceptable. >>>>> >>>>> We don't need to go through a long list of historical events or >>>>> personal >>>>> experiences. Let's just keep it down to the facts. >>>>> >>>>> LL decided to put the SecondLife code into open source, available for >>>>> everyone everywhere. As such any approach of security through >>>>> obscurity >>>>> is doomed to fail. >>>> >>>> It is not as much as ensuring "security via obscurity", than to avoid >>>> giving to script kiddies, wannabe hackers and griefers an easy recipe >>>> for hacking SL before the vulnerability is plugged. >>>> >>>>> .../... >>>>> I'd expect LL to provide regular security bulletins in an organized >>>>> way, >>>>> accessible to all users who would be interested in them. That does >>>>> not >>>>> mean a detailed piece of code, but a clear description of the >>>>> vulnerability and the risk. >>>> >>>> Mind you, a very large number of Open Source project (I could cite the >>>> Linux kernel itself !) sometimes do delay the publication of a >>>> vulnerability so to prevent major security risks. Describing what >>>> feature is flawed is just a pointer to where to lok at in the code, >>>> so even if you don't give a piece of code as a proof of concept to >>>> demonstrate how someone could exploit a vulnerability, you still >>>> give directions to hackers as to where to search. Admitedly, this >>>> would only permit to true hackers to find out a proper exploit, >>>> but it is still a big risk to take. >>>> >>>>> A good distribution list reaching dedicated people would indeed be >>>>> the SLDev mailing list. So that developers can decide what to do, >>>>> perhaps help to fix it in faster way than LL would be able to or >>>>> is unwilling to do, or if this is not possible to provide >>>>> recommendations such as not to use a particular version of the >>>>> viewer. >>>> >>>> Depending on the vulnerability and what risk it involves, this list >>>> is indeed good enough. Even the SL grid status blog could do... >>>> >>>> Examples: >>>> >>>> 1.- A vulnerability is discovered in the viewer that allows people >>>> to crash it via a particular set of parameters (in a prim, a media, >>>> etc). >>>> >>>> There is no big risk here, but for "standard" griefing which can >>>> easily be dealt with or worked around (by muting the griefer for >>>> example). >>>> >>>> In this case, the vulnerability and the work around should be made >>>> public on the grid status blog so that everyone is aware of it >>>> and knows what to do should the vulnerability hit them before a >>>> definitive fix is published. >>>> >>>> 2.- A vulnerability is discovered that would allow a clever hacker >>>> using their own hacked simulator (on an OpenSim grid) to rob money >>>> to people visiting their sim. >>>> >>>> The risk higher, here, and it is best to restrict the audience of >>>> people who will be aware of how to exploit the vulnerability. >>>> Publishing the details on the sldev list would be fine, and a >>>> warning shall also be published on the SL and OpenSim blogs to >>>> warn people and ask them to avoid connecting to OpenSim servers >>>> they don't trust till a new version of the viewer is published. >>>> >>>> 3.- A vulnerability is discovered internally by LL that would allow >>>> to steal money on the SL grid via a particular set of parameters >>>> (in a prim, a media, etc). >>>> >>>> This is a very high risk vulnerability (it does not even involve >>>> hacking a server, but only providing a crafted asset in a standard >>>> sim), and it is likely that only LL is aware of it so far. >>>> >>>> I do think such a vulnerability shall *not* be disclosed until >>>> a proper fix id found, possibly associating trusted third parties >>>> developpers. >>>> Once the fix is found, all the developpers of the third parties >>>> viewers should recieve the patch and some time should be left for >>>> them to publish updated versions of their viewers, time during which >>>> LL would publish their own official version. >>>> Only then, should the vulnerability be disclosed to the public. >>>> >>>>> I remember that last security disaster in the 1.20.17 version. LL >>>>> decided to work behind closed doors. Even though a fix was internally >>>>> available it was not provided in source / patch form to 3rd party >>>>> developers, >>>> This is not entirely true... LL did indeed not tell anyone about >>>> the vulnerability until they had fixed it, but then the updated code >>>> was provided to third parties developpers. Admitedly, this latter >>>> part could have been optimized and this is exactly what Rob proposed >>>> with the dedicated vulnerability list. >>>> >>>>> leaving 10's if not 100's of thousand users vulnerable. >>>> >>>> Partially true: but till a fix is found, anyone is vulnerable anyway. >>>> Not disclosing the vulnerability at least prevented script kiddies >>>> and wannabe hackers to exploit it... so, I personally thing it was >>>> the right thing to do. >>>> >>>>> It was only made available several days later through obscure >>>>> channels to a handful of developers who asked for. >>>> >>>> Here again, not entirely true: an announce was publiches on this >>>> list, asking to third parties developpers to contact Rob. >>>> Admitedly, this was not the fastest and easiest of the processes, >>>> thus the interest of a list. >>>> >>>>> And it was half hearted as LL decided not to backport the security >>>>> patches to the 1.19 pre-windlight viewers but left that task >>>>> completely to the developers of alternative viewers. >>>> >>>> Yes, I did the backport to v1.19. But although I regret (and tell >>>> it on every occasion, like now) that LL does not maintain a viewer >>>> with the legacy renderer any more (thus letting people with 3 years >>>> old computers without a usable and resonably fast viewer for their >>>> machine), I cannot blame them for not providing a fix to a >>>> discontinued branch of the viewer... >>>> Take Firefox... v1 has been discontinued even though it's the only >>>> version that can run reasonnably fast on old, i586 computers (thanks >>>> to GTK+ v1 which is much less bloated than v2 and runs twice or thrice >>>> faster). Firefox v2 will soon be discontinued too... there are no >>>> security fix for discontinued Firefox branches: that's life... >>>> >>>>> The only way to mitigate the risk was to tell people not to use in >>>>> our case the Cool Viewer as the vulnerability and risks were unknown. >>>> >>>> The Linux version of the Cool SL Viewer (both v1.19 and v1.20) was >>>> fixed within 24 hours of the release of the official LL viewer... >>>> Not that dramatic, but a dedicated mailing list would definitely help >>>> reducing such delays down to 0. >>>> >>>> >>>> So, to summarize, I'll just say that: >>>> >>>> There is no simple rule as to whether or not all vulnerabilities >>>> shall be disclosed. It all depends on how severe is the vulnerability, >>>> on who discovered it, and whether there is an existing work around or >>>> not. >>>> >>>> If the vulnerability is severe, *and* was discovered internally by LL >>>> *and* has no work around, then it is definitely safer for everyone to >>>> fix it internally, publish the patch only to third parties vewiers >>>> makers, and only after everything is pluged, tell everyone else about >>>> it and ask them to update immediately. >>>> >>>> Henri. >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> -- >> Tateru Nino >> http://www.massively.com/ >> > > From GordonWendt at gmail.com Sun Dec 28 21:37:58 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sun Dec 28 21:38:03 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49585FA9.8030505@gmail.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> <20081227204439.7e5d6f49.sldev@free.fr> <4957A4E5.2070204@weblogsinc.com> <49585FA9.8030505@gmail.com> Message-ID: <493033a70812282137i2fa2bed9mc8fbb87a755ea8d4@mail.gmail.com> On the topic of NDA's I forgot who mentioned it earlier but I don't think the idea of a pseudonym based NDA is actually possible and Rob please correct me if I'm wrong but I think you need a lot more than just your real name for it to be a binding document which essentially makes it a non starter as an idea because many people will refuse to participate because of this which will essentially make any list that requires one useless. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081229/214cd140/attachment.htm From tateru.nino at gmail.com Sun Dec 28 21:52:16 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Dec 28 21:52:20 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <493033a70812282137i2fa2bed9mc8fbb87a755ea8d4@mail.gmail.com> References: <329370.24473.qm@web63808.mail.re1.yahoo.com> <57606.68.88.68.118.1230310898.squirrel@mail.lindenlab.com> <104458.53743.qm@web63804.mail.re1.yahoo.com> <20081227204439.7e5d6f49.sldev@free.fr> <4957A4E5.2070204@weblogsinc.com> <49585FA9.8030505@gmail.com> <493033a70812282137i2fa2bed9mc8fbb87a755ea8d4@mail.gmail.com> Message-ID: <49586590.8020507@weblogsinc.com> They hold water in a few jurisdictions, including the USA and the UK. It's not uncommon to have documents and contracts with nom de plumes or nom de guerres. Even Social Security accepts them, so long as they're certain you're not doubling up or using them "with intent to deceive or defraud". Gordon Wendt wrote: > On the topic of NDA's I forgot who mentioned it earlier but I don't > think the idea of a pseudonym based NDA is actually possible and Rob > please correct me if I'm wrong but I think you need a lot more than > just your real name for it to be a binding document which essentially > makes it a non starter as an idea because many people will refuse to > participate because of this which will essentially make any list that > requires one useless. > > -G.W. > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://www.massively.com/ From robla at lindenlab.com Sun Dec 28 23:11:26 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Dec 28 23:11:42 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49551DCC.7040403@lindenlab.com> References: <49518443.7050107@lindenlab.com><105c09f0812241413k4ba6f682lb989af81b37e52e2@mail.gmail.com> <49551DCC.7040403@lindenlab.com> Message-ID: <4958781E.9030804@lindenlab.com> Hi everyone, It sounds like everyone who has 2 cents to chip in on this subject has done so. Key takeaways from this conversation: * There were a number of people who expressed skepticism about the effectiveness of having a formal non-disclosure agreement (NDA) versus a trust relationship. Some form of NDA may end up being a necessary part of this, but the questions of added effectiveness are noted. * There were a couple of people who described a strong desire to be able to maintain their anonymity. I understand the reasons for wanting this, and will look into whether it is possible to accommodate this. * There were people that argued pretty passionately on both sides of the argument about whether or not an early disclosure group should exist. There wasn't consensus on this point (and I doubt we'll arrive at consensus), but the arguments are all out there to deliberate on. Here's what I imagine the next steps: 1. I will continue to collect requests for membership in this group. If you haven't done so, and believe you have a case to be in this group, please let me know via private email (and state your reasons for being considered). 2. I need to loop back with more people at Linden Lab to make a determination about how to we want to move forward. I feel I've got a reasonably accurate take on what the various positions are and can speak to them pretty well. 3. In the next month, you should expect to see us announce a policy, or else see a sheepish email from me around the end of January saying "we're still working on it". I really don't want to write a sheepish email, but know if I don't acknowledge the possibility, then it's just that much more likely I'll have to write it. Should the need arise for such a group in the interim period, we'll have to improvise. I feel like having had that conversation, we're in a better position to improvise than we would be otherwise. Thanks everyone for your input, and for those of you who try to avoid these sorts of policy conversations, thanks for your patience. Rob From GordonWendt at gmail.com Sun Dec 28 23:59:31 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sun Dec 28 23:59:36 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <4958781E.9030804@lindenlab.com> References: <49518443.7050107@lindenlab.com> <105c09f0812241413k4ba6f682lb989af81b37e52e2@mail.gmail.com> <49551DCC.7040403@lindenlab.com> <4958781E.9030804@lindenlab.com> Message-ID: <493033a70812282359m7a438359laf3d12b37ea01c83@mail.gmail.com> Rob, from the attitude conveyed by your email this seems like another big screw you towards a lot of people. I honestly didn't expect LL to ditch the plan to create this list even though there's vocal opposition to it even had the opposition outweighed the support (it didn't) but the fact that your message conveyed the tone that it was off the table is essentially saying to me and to others that it wasn't even on the table and you were jerking us along. If it wasn't a viable option you should have told us so when you laid out the other non viable options. I would say I'm disappointed but I don't want to sound like I'm whining and I think by this point I don't think I have to tell you that Rob. Since I assume you won't publicly answer me on list since you never do I'll await either silence or your reply via email. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081229/1443ab8d/attachment-0001.htm From alissa_sabre at yahoo.co.jp Mon Dec 29 04:31:43 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Dec 29 04:31:50 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <49551DCC.7040403@lindenlab.com> References: <49551DCC.7040403@lindenlab.com> Message-ID: <74Lc6e08dYtdscs0m86Ps.alissa_sabre@yahoo.co.jp> Rob, > Great discussion! This issue continued more than five messages. This issue seems non technical. Why didn't you stop the dicussion? Well, I believe this issue is important for many of SLDev subscribers and is worth discussing on the list, so I have no objection to see the discussion continues. However, Rob, you *are* the guardian of the list, and you should not ignore your rule. ... Anyway, > Option 1: Linden Lab creates a vulnerability early disclosure group, > admitting people into the group based on their need to know and track > record of reliability, honesty and discretion. "Need to know" is > limited to people or organizations that distribute viewers used by a > wide audience, or some other very compelling reason to know. This group > would get notice of some details regarding a vulnerability when Linden > Lab becomes aware of a problem, and receive the patch early when Linden > Lab has an untested fix that's ready for incorporation. The time > between early disclosure (when this group knows about a problem) and > general disclosure (when the general public knows about the problem) > would likely be a period best measured in days, not weeks or months. > > Option 2: similar to option #1, with the addition of an explicit, > signed non-disclosure agreement as a prerequisite for joining the group. I prefer option 2 *minus* a particular phrase "used by a wide audience" in the sentense "Need to konw is limited to people or organizations that distribute viewers used by a wide audience, or some other very compelling reason to know." in the explanation of option 1. I believe "used by a wide audience" is not a good cirteria. I believe the first priority objective of the early disclosure is to protect SL residents who are using a third party viewer. Disclosing vulnerability information only to developpers of a viewer with _a_wide_audience_ means that viewer developpers without a wide audience will not receive the vulnerability info timely. The consequence of this policy is that users of a viewer with a wide audience get timely security fix, and those of a viewer without a wide audience doesn't. If it is the case, who would choose a viewer without a wide audience? As a result, a policy to disclose to viewer developers that already have a wide audience will effectively kills new third party distribution in a future, because nobody can get a wide audience from the beginning. On the other hand, I believe the early disclosure should be to as small group as possible. I also believe the people who receive vulnerability info earlier than ordinary residents should be limited to trustworthy ones. I support the idea to mandate an NDA, so that we can limit the number of people as well as we can limit to responsible people. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From carjay at gmx.net Mon Dec 29 05:27:29 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Dec 29 05:27:50 2008 Subject: [sldev] [Compiling/Error] Error: the command 'make' exited with status 2 In-Reply-To: <2da30a0e0812290424y17c42ebybcf66e4556dc39b9@mail.gmail.com> References: <2da30a0e0812250348i20f31450wdbc7037657933ff7@mail.gmail.com> <4953AB9E.2090908@gmx.net> <2da30a0e0812260834y612dac97he02e9d5d9d14c356@mail.gmail.com> <49557A4A.2020109@gmx.net> <2da30a0e0812290424y17c42ebybcf66e4556dc39b9@mail.gmail.com> Message-ID: <4958D041.2010206@gmx.net> Hello Mikkel, the important error is obviously this: [ 31%] Building CXX object llrender/CMakeFiles/llrender.dir/llcubemap.o In file included from /home/xuxiix/Desktop/asdf/linden/indra/llrender/llglheaders.h:70, from /home/xuxiix/Desktop/asdf/linden/indra/llrender/llgl.h:48, from /home/xuxiix/Desktop/asdf/linden/indra/llrender/llcubemap.h:35, from /home/xuxiix/Desktop/asdf/linden/indra/llrender/llcubemap.cpp:35: /home/xuxiix/Desktop/asdf/linden/indra/../libraries/i686-linux/include/GL/glx.h:38:22: error: X11/Xlib.h: No such file or directory /home/xuxiix/Desktop/asdf/linden/indra/../libraries/i686-linux/include/GL/glx.h:39:23: error: X11/Xutil.h: No such file or directory It can't find the X11 headers. Usually these are installed with a development package like libxt-dev. See "Prerequisites for Linux" on http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake They should pull in all required packages at least on debian. Carsten Mikkel Hansen wrote: > Hi, > > sorry, again, for the slow(er) response! I'm somewhat limited to the > internet at this moment, so... > > Anyway, I've attached the log. I noticed that there are way more > errors there, than in the terminal, for some reason. > > Mikkel > > > 2008/12/27 Carsten Juttner > > > Hello Mikkel, > > easiest is to simply redirect any (stdout and stderr) output to a > file by typing this: > make > log.txt 2>&1 > > > Carsten > > > > Mikkel Hansen wrote: > > Hi, sorry about the slow response. > > How do I post the complete log? I only see a few lines in the > terminal. > > Thanks, > Mikkel > > Carsten Juttner wrote > > > Hello Mikkel, > > could you please post the complete log? > > It only shows that make stops but it does not say where and > why. > > Sometimes the position of the error is several lines before > make > actually stops. > > > Regards, > Carsten > > > > Mikkel Hansen wrote: > > Well, I'm relatively new to C++, compiling, mailinglists, > etc... Anyway, when I try to compile the viewer I get an > error. I'm on Linux Mint using cmake-SL to build the > client. > I've applied one patch > (https://jira.secondlife.com/browse/VWR-10001) to get > past an > error earlier, however, now I'm stuck again. D: > > I get the following error: > > ... > [ 31%] Building CXX object > llmessage/CMakeFiles/llmessage.dir/patch_dct.o > [ 31%] Building CXX object > llmessage/CMakeFiles/llmessage.dir/patch_idct.o > Linking CXX static library libllmessage.a > make[2]: Leaving directory > `/usr/src/SL/indra/viewer-linux-i686' > [ 31%] Built target llmessage > make[1]: Leaving directory > `/usr/src/SL/indra/viewer-linux-i686' > make: *** [all] Error 2 > make: Leaving directory > `/usr/src/SL/indra/viewer-linux-i686' > Error: the command 'make' exited with status 2 > > > I am not sure if you need the version name/whatever I am > trying to compile, although if you do, I'll tell you. :p > > Thanks > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > From robla at lindenlab.com Mon Dec 29 18:39:52 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Dec 29 18:40:10 2008 Subject: [sldev] Viewer security vulnerability disclosure group In-Reply-To: <74Lc6e08dYtdscs0m86Ps.alissa_sabre@yahoo.co.jp> References: <49551DCC.7040403@lindenlab.com> <74Lc6e08dYtdscs0m86Ps.alissa_sabre@yahoo.co.jp> Message-ID: <495989F8.3020603@lindenlab.com> On 12/29/08 4:31 AM, Alissa Sabre wrote: >> Great discussion! >> > > This issue continued more than five messages. This issue seems non > technical. Why didn't you stop the dicussion? > > Well, I believe this issue is important for many of SLDev subscribers > and is worth discussing on the list, so I have no objection to see the > discussion continues. However, Rob, you *are* the guardian of the > list, and you should not ignore your rule. > > You're right. Here's the JIRA issue: http://jira.secondlife.com/browse/VWR-11305 I'll respond to some of the points you raised in this thread there. Additionally, I've made a proposal to rework the guideline here: https://wiki.secondlife.com/wiki/Talk:SLDev#Per_person.2Fthread_limit_on_conversation.3F I might be biased because this is an issue that I raised and thus was more interested in it, but I think the conversation on this issue didn't set off red flags for me in the same way that past conversations have because most folks were both civil and didn't try to hog the microphone, so to speak. Rob From leonel.morgado at gmail.com Wed Dec 31 09:05:11 2008 From: leonel.morgado at gmail.com (Leonel Morgado) Date: Wed Dec 31 09:05:34 2008 Subject: [sldev] =?windows-1252?q?Vote_for_change_in_virtual_worlds=3A_le?= =?windows-1252?q?t=92s_put_e-democracy_to_a_test!?= Message-ID: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> >From http://gwynethllewelyn.net/2008/12/31/lets-put-e-democracy-to-a-test/ Barack Obama's change.org website is accepting requests for ideas and projects to be implemented during his term. Knowing that he's all for technological innovation, and that several successful experiments with e-democracy were done inside Second Life(R), let's try to push for even more. Andabata Mandelbrot is proposing that we vote to create an international metaverse - the Internet equivalent of virtual worlds . To get this implemented, we need 400 votes! And the deadline is? today at midnight, so we need to hurry? Voting is simple, you just need to create an account on the change.orgaccount and vote (you can even log in with your Facebook or MySpace account) by clicking on the icon. If you're willing to promote this idea, you can, of course, do more ? add widgets, push it to your social network, and so on. With a surprisingly open-minded approach, voting is *not*limited to US residents, but it's totally open to international voters too. The change is for America, but its impact will be global. A nice touch! Why should President-Elect Obama listen to this proposal? Well, we know that he has appointed two Second Life Innovators to his "Innovation Agenda" group . And his virtual presence in SL was serious, well-planned, and part of his campaign. He's no stranger to using virtual worlds as a political ? but also democratic ? platform. So he might very well take notice of this proposal, specially if he can see the support it gathers. It's up to us to put democracy in practice ? with the vote [image: :)] Vote now and get your friends in SL to do the same! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081231/26ed01ac/attachment.htm From tom at streamsense.net Wed Dec 31 09:11:56 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Dec 31 09:12:19 2008 Subject: =?windows-1252?Q?Re=3A_=5Bsldev=5D_Vote_for_change_in_?= =?windows-1252?Q?virtual_worlds=3A_let=92s_put_e-democracy_to_?= =?windows-1252?Q?a_test!?= In-Reply-To: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> References: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> Message-ID: <495BA7DC.5070208@streamsense.net> I'm sorry, but this is really not relevant to this list. In case you didn't notice, the metaverse is already international :P and those of us outside of the USA couldn't really care less about what your new president does. ~T Leonel Morgado wrote: > > but it's totally open to international voters too. The change is for > America, but its impact will be global. A nice touch! > From leonel.morgado at gmail.com Wed Dec 31 09:33:49 2008 From: leonel.morgado at gmail.com (Leonel Morgado) Date: Wed Dec 31 09:33:57 2008 Subject: =?WINDOWS-1252?Q?Re:_[sldev]_Vote_for_change_in_virtual_?= =?WINDOWS-1252?Q?worlds:_let=92s_put_e-democracy_to_a_test!?= In-Reply-To: <495BA7DC.5070208@streamsense.net> References: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> <495BA7DC.5070208@streamsense.net> Message-ID: <80cf01370812310933u1a23c624pd5050b0d45a692a1@mail.gmail.com> Hi Tom, I beg to disagree. I find it relevant - that's why I posted it. I am not an American - that's a great thing about change.org - you can contribute with ideas, even if you're not an American citizen. The metaverse is international, but it isn't a reality: you are in Second Life, but you cannot take your avatar and creations to other virtual worlds, not even to Open Sim. Even existing efforts, like the cross-grid announcement by Linden Lab and IBM recently, cover little more than an avatar's name. Anyone should be able to host a virtual world server and let other people visit it, seamlessly - like anyone can host a Web page. That is what this proposal is all about. It impacts research, education, business, it impacts Second Life, but also other virtual worlds. Int?, Leonel On Wed, Dec 31, 2008 at 5:11 PM, Thomas Grimshaw wrote: > I'm sorry, but this is really not relevant to this list. > > In case you didn't notice, the metaverse is already international :P and > those of us outside of the USA couldn't really care less about what your new > president does. > > ~T > > > Leonel Morgado wrote: > >> >> but it's totally open to international voters too. The change is for >> America, but its impact will be global. A nice touch! >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081231/db6800fb/attachment.htm From tom at streamsense.net Wed Dec 31 09:37:37 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Dec 31 09:37:53 2008 Subject: =?windows-1252?Q?Re=3A_=5Bsldev=5D_Vote_for_change_in_?= =?windows-1252?Q?virtual_worlds=3A_let=92s_put_e-democracy_to_?= =?windows-1252?Q?a_test!?= In-Reply-To: <80cf01370812310933u1a23c624pd5050b0d45a692a1@mail.gmail.com> References: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> <495BA7DC.5070208@streamsense.net> <80cf01370812310933u1a23c624pd5050b0d45a692a1@mail.gmail.com> Message-ID: <495BADE1.70600@streamsense.net> Then, you really want to petition the International Organisation for Standardization and not the united states president elect. http://www.iso.org/iso/home.htm ~T Leonel Morgado wrote: > Hi Tom, > > I beg to disagree. I find it relevant - that's why I posted it. > I am not an American - that's a great thing about change.org > - you can contribute with ideas, even if you're > not an American citizen. > > The metaverse is international, but it isn't a reality: you are in > Second Life, but you cannot take your avatar and creations to other > virtual worlds, not even to Open Sim. Even existing efforts, like the > cross-grid announcement by Linden Lab and IBM recently, cover little > more than an avatar's name. > > Anyone should be able to host a virtual world server and let other > people visit it, seamlessly - like anyone can host a Web page. > That is what this proposal is all about. > > It impacts research, education, business, it impacts Second Life, > but also other virtual worlds. > > Int?, > > Leonel > > On Wed, Dec 31, 2008 at 5:11 PM, Thomas Grimshaw > wrote: > > I'm sorry, but this is really not relevant to this list. > > In case you didn't notice, the metaverse is already international > :P and those of us outside of the USA couldn't really care less > about what your new president does. > > ~T > > > Leonel Morgado wrote: > > > but it's totally open to international voters too. The change > is for America, but its impact will be global. A nice touch! > > > From leonel.morgado at gmail.com Wed Dec 31 09:41:41 2008 From: leonel.morgado at gmail.com (Leonel Morgado) Date: Wed Dec 31 09:41:47 2008 Subject: =?WINDOWS-1252?Q?Re:_[sldev]_Vote_for_change_in_virtual_?= =?WINDOWS-1252?Q?worlds:_let=92s_put_e-democracy_to_a_test!?= In-Reply-To: <495BADE1.70600@streamsense.net> References: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> <495BA7DC.5070208@streamsense.net> <80cf01370812310933u1a23c624pd5050b0d45a692a1@mail.gmail.com> <495BADE1.70600@streamsense.net> Message-ID: <80cf01370812310941o73d3573epa67b301d1f9d7f93@mail.gmail.com> If I'm not mistaken, the US military developed the ARPANET and that eventually became the Internet.So, an US-led approach can work. The ISO approach can also work. Or not. If you want to pursue that path, I'm entirely supportive of it. One thing doesn't prevent the other... what matters is the idea...bring virtual worlds from the BBS age (the current situation) to the Internet/metaverse age. Int?, Leonel On Wed, Dec 31, 2008 at 5:37 PM, Thomas Grimshaw wrote: > Then, you really want to petition the International Organisation for > Standardization and not the united states president elect. > http://www.iso.org/iso/home.htm > > ~T > > Leonel Morgado wrote: > >> Hi Tom, >> >> I beg to disagree. I find it relevant - that's why I posted it. >> I am not an American - that's a great thing about change.org < >> http://change.org> - you can contribute with ideas, even if you're not an >> American citizen. >> >> The metaverse is international, but it isn't a reality: you are in >> Second Life, but you cannot take your avatar and creations to other virtual >> worlds, not even to Open Sim. Even existing efforts, like the cross-grid >> announcement by Linden Lab and IBM recently, cover little more than an >> avatar's name. >> >> Anyone should be able to host a virtual world server and let other >> people visit it, seamlessly - like anyone can host a Web page. >> That is what this proposal is all about. >> >> It impacts research, education, business, it impacts Second Life, but >> also other virtual worlds. >> >> Int?, >> >> Leonel >> >> On Wed, Dec 31, 2008 at 5:11 PM, Thomas Grimshaw > tom@streamsense.net>> wrote: >> >> I'm sorry, but this is really not relevant to this list. >> >> In case you didn't notice, the metaverse is already international >> :P and those of us outside of the USA couldn't really care less >> about what your new president does. >> >> ~T >> >> >> Leonel Morgado wrote: >> >> >> but it's totally open to international voters too. The change >> is for America, but its impact will be global. A nice touch! >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081231/33e50c6d/attachment-0001.htm From lenglish5 at cox.net Wed Dec 31 10:00:43 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Dec 31 10:00:46 2008 Subject: =?windows-1252?Q?Re=3A_=5Bsldev=5D_Vote_for_change_in_?= =?windows-1252?Q?virtual_worlds=3A_let=92s_put_e-democracy_to_?= =?windows-1252?Q?a_test!?= In-Reply-To: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> References: <80cf01370812310905y39f06dfcrcbd6fa4e257727ba@mail.gmail.com> Message-ID: <495BB34B.1060106@cox.net> Leonel Morgado wrote: > > From http://gwynethllewelyn.net/2008/12/31/lets-put-e-democracy-to-a-test/ > > Barack Obama's change.org website is accepting > requests for ideas and projects to be implemented during his term. > Knowing that he's all for technological innovation, and that several > successful experiments with e-democracy were done inside Second Life?, > let's try to push for even more. Andabata Mandelbrot > is proposing that we vote to create an > international metaverse - the Internet equivalent of virtual worlds > . > My response in the comments section: There are already several competing groups trying to accomplish this. The SL-related one involves the AWG/OGP initiatives started by Linden Lab. I think that requesting better *funding* for such groups might be appropriate, but calling for standardization at this point is premature. Let 3 or 4 or 5 such groups compete with equal government funding and see what shakes out, or merges, or whatever. Lawson From dooglio at gmail.com Wed Dec 31 11:19:17 2008 From: dooglio at gmail.com (R. Douglas Barbieri) Date: Wed Dec 31 11:19:20 2008 Subject: [sldev] Failed build on x86_64, failed including glib? In-Reply-To: <3bb9647e0812261004j5264d095q5285535259c02dc3@mail.gmail.com> References: <3bb9647e0812252301m412e0f07o81315c7e59167694@mail.gmail.com> <200812260310.58155.dnbyena@gmail.com> <3bb9647e0812261004j5264d095q5285535259c02dc3@mail.gmail.com> Message-ID: <367cdf400812311119x8a18928ya40b157e4844fcc3@mail.gmail.com> If I remember correctly, I ran into a similar problem on my Ubuntu x64 system. I installed the glib dev package and it built correctly. On Fri, Dec 26, 2008 at 10:04 AM, Ricky wrote: > Thanks! I'll check out the overlay, and try your suggestions. > > Ricky > aka Cron Stardust > > On Fri, Dec 26, 2008 at 12:10 AM, Khyota wrote: >> >> >Any ideas? >> You forgot to add --standalone to # ./develop.py -t Release -N. so # >> ./develop.py --standalone -t Release -N? your trying to compile against >> the >> precompiled librarys, and glib isnt included for x86_64 yet. >> >> you may also need to grab the libs, SDL, and glh_linear packages from >> install.xml SDL contains the missing cursors which arent in artwork for >> some >> reason, and glh_linear is needed but isnt downloaded in standalone, the >> libs >> contains fonts but if your replacing them its fine. >> >> If your compiling svn trunk you will need to compile libndofdev seperatly >> and >> LL does not provide the source so here it is. >> >> http://www.aaue.dk/~janoc/files/software/linux/spacenav/libndofdev-0.2.tar.gz >> (thanks jan) >> >> Thats extra work for going x86_64 these days :/ >> you mite also want to check out the gentoo ebuild, might also help solve >> the >> dependancy mess and give you a 'skeleton' for your script, its on the >> zugaina >> overlay, but heres a url to the latest one too. >> >> http://gentoo.zugaina.org/portage/games- >> simulation/secondlife/secondlife-1.22.4_rc.ebuild >> >> Happy building! >> >> Khyota >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Doug Barbieri dooglio@gmail.com From robla at lindenlab.com Wed Dec 31 11:26:47 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Dec 31 11:26:53 2008 Subject: [sldev] Making the build instructions better Message-ID: <495BC777.6090508@lindenlab.com> Hi all, I've updated the build instructions on Linux: http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) I'd love to get some eyeballs on this, and see things get better there. Here's the umbrella page for all platforms http://wiki.secondlife.com/wiki/Get_source_and_compile Currently, the page is split up into platform specific prep pages, and then a general "CMake" page after that. Michelle2's page is consolidated into one big page. Which is the better approach? Rob From benglenn at lindenlab.com Wed Dec 31 11:29:13 2008 From: benglenn at lindenlab.com (Ben Glenn) Date: Wed Dec 31 11:29:15 2008 Subject: [sldev] UX Office Hour Message-ID: <024101c96b7e$10294040$307bc0c0$@com> Hi all, Due to the holiday tomorrow, we'll be having our monthly UX office hour on 1/8 instead. Happy New Year! Ben Ben Glenn Director, User Experience Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081231/1d96edb1/attachment.htm