The reason I needed this 'hack' was to stop servers downloading lua files into GMod's autorun folders (which is open to all kinda of dumb attacks from dumb server admins, ie adding a timer to make you say "this server sucks" every 10 seconds). AFAIK there's no real way to handle this without this hack.
That said, I'm all for a callback allowing the client.dll to reject the download rather than blocking files for all mods. But even if that happens I don't know how much that will help you, since it'd probably have to happen in the EP2 code and I don't know whether you're going to bother porting FF to the new engine. garry On 10/19/07, Jeremy <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Lua is as safe as you make it, as is any scripting language. It's up to the > developer to limit what sort of access it can have to the mod/system. Our > map scripts aren't dynamically executable, they are server side only. We > don't have any such thing as client side lua. However, the server sending > the maps to the clients leave them with a useless map unless they also have > the script. They won't be able to host the map themselves, run around in a > listen server, etc. Blocking *.lua is a hack. If a mod supports lua and > leave the default bindings wide open to open/edit files in arbitrary > directories then yes it will be abused. Like I said, it's as safe as you > want to make it. I'm not familiar with how it was being abused in garrys > mod, and it doesn't really matter to me, because we need to be able to send > them in a reasonable fashion(not hacking around it by making up some new > extension, using txt files, or packing them in the bsp or something). I > would still like an official answer on this please. > > Jeremy > > On 10/19/07, Kevin Ottalini <[EMAIL PROTECTED]> wrote: > > > > Jeremy, > > Downloading dynamic execuatble /scriptable files to clients from > > servers > > is always a big no no since they can be (and will be) abused. > > > > From the documentation, lua does not appear to be a safe solution. > > > > > > > > ----- Original Message ----- > > From: "Jeremy" > > To: <[email protected]> > > Sent: Friday, October 19, 2007 10:56 AM > > Subject: Re: [hlcoders] Adding downloads via downloadables table > > > > > > > I read you the first time, and like I said, that's not a solution for > > how > > > we > > > use map scripting. I would like a real solution from Valve. Blocking lua > > > files from downloading across all mods because of one mod was a pretty > > > rash > > > decision, and one that should be reversed and left up to each mod to > > > filter > > > file extensions as desired. engine->DisallowDownload(extension) or > > > something > > > simple like that. Had this problem been identified before we released we > > > might have worked around it by using a different extension, ff_lua or > > > something. But post release, and after there is a number of 3rd party > > maps > > > already in the wild, we need to be able to accommodate lua files. > > > > > > > > > On 10/19/07, Mark Chandler wrote: > > >> > > >> Add it to the bsp using pakrat > > >> > > >> On Oct 19, 2007, at 2:10 PM, Jeremy wrote: > > >> > > >> > We use lua to go along with our maps, and I'm trying to get the > > >> > server to > > >> > automatically send the lua files to the clients like it already does > > >> > the > > >> > maps. After messing with it a bit trying to get it to work, I tried > > >> > a text > > >> > file and it worked, so it appears that lua files are filtered/ > > >> > excluded from > > >> > being able to be downloaded. Is there any way to get around this? In > > >> > our mod > > >> > at least, the map files are incomplete without the lua files, so the > > >> > clients > > >> > can start their own server with the maps unless they get the lua > > >> > files from > > >> > somewhere else. Obviously that's not practical when it would be best > > >> > if we > > >> > could get the engine to send them the lua file as well. There a way > > >> > to do > > >> > this? > > >> > > > >> > J > > > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
