This is a security flaw in the platform of SL. Period. Report it or I will.
- Timeless Prototype On 09/07/06, Jesse Nesbitt <[EMAIL PROTECTED]> wrote:
I disagree. I think that compiling in the upload sink doesn't fit. Something tells me that this might force a fork in the codebase (and I do not want to see that) As for your XChat refrence, there are MANY people that provide free XChat builds for windows. Just by 2.5 cents. --Jesse On 7/9/06, Adam Frisby <[EMAIL PROTECTED]> wrote: > Weighing in here - sure it's possible to compile out the upload fees - > but the default should be to enforce them. > > People are going to get around things to avoid paying - that's a fact of > life, but as the library developers we do have some obligation to make > sure our client behaves with SL. > > To bring up an example - the windows version of X-Chat has a $15 > registration fee? Count the number of people who have been bothered to > actually compile that out. Most just dont bother, pay the fee and be > done with it. (or avoid using it) > > Until LL starts enforcing these serverside themselves, I think we have > the obligation to make sure something we are at least partially > responsible for doesnt kill the asset system, and at the end of the day, > on the technical side, it should be fairly trivial to implement. > > -Adam > > Alondria LeFay wrote: > > > I think LL would be much more concerned with us having the programmatic > > way of creating assets than whether we are enforcing their money sink > > within it. Historically, they have held fast to not allowing LSL to > > create assets due to the fear that someone could bring the asset server > > to its knees. My fear is somewhat that when we do implement this, > > someone will end up taking out the asset server. Likewise, if someone > > makes a "free upload program" it could throw our economy on SL more out > > of wack. > > > > > > > > I think the end result is we really need to think this one through and > > perhaps we should talk to LL about the situation and what can be done to > > ensure libsl sill not cause more harm than good. > > > > > > > > Thus, I somewhat disagree – I think we do have some responsibility to > > ensure what we do is for the common good and seriously think about the > > possible fallout of what we do. I also believe if we cause too much > > negative effects to SL and LL, LL will change their opinion and start > > inhibiting libSL's development. > > > > > > > > But – I haven't had my morning coffee yet…. > > > > > > > > ------------------------------------------------------------------------ > > > > *From:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *On Behalf Of *Tom Wilson > > *Sent:* Sunday, July 09, 2006 8:49 AM > > *To:* Development list for libsecondlife > > *Subject:* Re: [libsecondlife-dev] Inventory Upload & Fees > > > > > > > > I'm sorry, but it just doesn't make sense to enforce upload payments in > > libSL. > > > > lilbSecondLife is open source, and unless you close the source (and > > obfsucate it and use a language that's NOT C#), everybody who wants to > > cheat and upload for free would simply modify the upload routine and rip > > out the payment code anyway. If you closed certain modules to prevent > > that, you're going against the very idea of open source. It is not our > > job to make policy, and we are also not in the business of enforcing > > LL's policies. > > > > Also, just from a pure technical perspective, payments and uploads > > really have nothing to do with each other. It would be bad design to > > build payments in to the texture upload function. However, if payments > > and uploads happen together frequently (as they would with texture > > uploads), then it would be smart to either introduce a second, > > overloaded function or a new function that allows the user to specify > > the payment amount as a parameter. The function would return an error > > condition if there wasn't enough money in the person's account. > > > > IMO, paying for uploads should have been a server-side function all > > along, and I don't doubt that LL *will* implement that server side as > > soon as they figure out that people are adding assets to the server > > without paying to do it. (To do otherwise is simply bad design from a > > security standpoint.) I assume that you're already talking to a Linden > > once in a while: I'd suggest e-mailing that contact and commenting on > > this. I have a feeling that we'd see a change in the .12 release. > > > > I have no doubt that as people start leveraging libSL in their programs > > that LL will have their hands full trying to keep up with the things > > people have figured out how to do. Free uploads are just the tip of the > > iceberg. Now that LL's official position is "we encourage beneficial > > reverse-engineering", Let LL worry about the bugs and security holes in > > their protocol and fix it. It's not our job. :-) > > > > On 7/9/06, *Adam Frisby* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > Since inventory upload (aka automated asset creation) has been made > > possible via the CRC discovery, I think it might be the time to raise > > some important questions. > > > > 1. Upload fees are handled clientside, while I dont think this is the > > best approach for LL to take - it is something we need to deal with. Do > > we implement this? (Personally, I think there's a responsibility to > > implement them.) > > > > 2. Automated uploads is now possible for more than just textures - > > eventually someone's going to think it might be a great idea to share > > files by uploading them as base64 encoded notecards - again I suggest we > > implement a charge, L$2-10/asset fair? > > > > 3. Given the above, has anyone started implementing the code for > > handling asset creation? > > > > -Adam > > > > _______________________________________________ > > libsecondlife-dev mailing list > > libsecondlife-dev@gna.org <mailto:libsecondlife-dev@gna.org> > > https://mail.gna.org/listinfo/libsecondlife-dev > > > > > > > > > > -- > > Tom Wilson > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > KI6ABZ > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.394 / Virus Database: 268.9.10/383 - Release Date: 7/7/2006 > > > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.1.394 / Virus Database: 268.9.10/383 - Release Date: 7/7/2006 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > libsecondlife-dev mailing list > > libsecondlife-dev@gna.org > > https://mail.gna.org/listinfo/libsecondlife-dev > > > _______________________________________________ > libsecondlife-dev mailing list > libsecondlife-dev@gna.org > https://mail.gna.org/listinfo/libsecondlife-dev > -- --Jesse _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
