[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.0 (work3) now available
- From: Andrew Starks <andrew.starks@...>
- Date: Mon, 23 Jun 2014 07:52:38 -0500
On Monday, June 23, 2014, Thijs Schreijer <email@example.com> wrote:
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Behalf Of Andrew Starks
> Sent: maandag 23 juni 2014 2:12
> To: Lua mailing list
> Subject: Re: [ANN] Lua 5.3.0 (work3) now available
> On Sunday, June 22, 2014, Thijs Schreijer <firstname.lastname@example.org> wrote:
> BTW great to see the default package paths updated!
> Though I still think that the `!\?.dll` and `.\?.dll` c-paths should be
> removed, because they make it too easy for the casual user to put dll's into
> the system path (where other executables are also looking and might load
> them accidentally, as is the nature of Windows)
> 5.3 work3 package.cpath;
> The regular path has the `lua` subdirectory of the executable directory;
> `!\lua\?.lua`. Can't a similar subdirectory for clibs be added? So the dll's
> stay out of the system path, while the interpreter itself is in the system
> Proposed package.cpath;
> Obviously anyone could override it at any time, but imo at least the
> defaults should be as safe as possible.
> I lack an opinion about .\?.dll.
> I think that !\?.dll should stay. This is the way that Windows works,
> regardless of anyone's opinions about it. Executables go in the same spot
> that DLLs do.
I strongly disagree with your reasoning. Doing things the way you do it because you've always done it that way, is the worst possible reason. It's about the 'mother-of-all' security issues.
> In fact, getting Windows build tools and installers to do
> anything different is a pain.
True, but applications do not install themselves in the system path, they install shortcuts and links, and then `!\?.dll` is perfectly safe (and so it is for embedded Lua installations). But in this case, the standalone interpreter is generally in the system path. And the executable itself provides the options to put the dll's anywhere you want it through the configurable LUA_CPATH option.
I don't think there is single argument for keeping those two path elements, other than 'old habits die hard'.
> For this to be a security risk, it would also need to be one for all of the
> other libraries that do the same.
> It's at least one Stack Exchange trip with something along the lines of "I'm
> working with a legacy library that..."
Well, it depends.
If Lua's REPL is an application, then I could not agree with you more. Then every thing should go into USRPROFILE or APPDATA. If you're saying that won't happen and so they should do this as a compromise because lots of people use LuaRocks, then... Okay? It seems to me that one should be changing Lua rocks, but I follow the logic.
If Lua's REPL is a debugging tool and Lua is a C library that is to be embedded into an application, then I still don't follow you. The way that it works, works out of the box.
This goes back to the last thread. Lua does not have a Windows install script. Your suggestion makes things very slightly wonky for application developers in exchange for getting installed DLLs out of a users path, if they add the Lua install directory to that path. That's valid and I see your point.
I don't like the approach. A simple bat file in a contrib directory can put everything in its proper place, if the user wants to install Lua for use from the command line.
Failing that bat file, then this is pragmatic.
Is there a reason that you don't suggest putting the DLLs in the spot as the lua files? Such as in "luainstalldir\lua\?.dll"
I don't see the advantage to putting different parts of the module into different sub paths.