Hi, Today I imported the source code of the Lua library and removed it from the dependencies of Wesnoth. I didn't expect much opposition to it; I was wrong. So I'm sending a mail to this mailing list to explain my move.
First, the technical issue at hand: the Wesnoth engine uses C++ exception for control flow, while the Lua virtual machine uses C setjmp/longjmp. As a consequence, if we have a call stack: 1. C++, 2. Lua, 3. C++, 4. Lua, then there is a possibility that an exception is thrown from 3 to 1, leaving the Lua state inconsistent, or that a longjmp goes from 4 to 2, leaving the C++ engine in an unstable state (destructors not called, among other things). Until now, it hasn't been a security issue, because I have always been careful that none of the two scenarios above could occur. Unfortunately, this induces lots of noise in the source code, making it more complicated than necessary; for a few functions, it amounts up to 40% of the code. It also makes the code more difficult to grasp and modify for other developers. For instance, Crab, whom I consider a good C++ programmer, still needed several iterations to eliminate all the issues from his first patch to the Lua engine (AI support). Yet his original code was sensible. I trust him to carefully commit patches, but ideally, such a patch should have worked fine from the very start. One shouldn't have to wonder for every single line of code whether it potentially opens breaches. Lua developers are aware of this issue and they have devised a simple fix: just compile Lua with a C++ compiler and it will use exceptions instead of jumps, hence solving all the issues above. (Note that this whole issue is only for *nix systems. On Windows, exceptions and jumps are supposedly handled in a uniform way, so Windows maintainers can disregard the whole matter if they wish to.) So, you have it: I imported the Lua code so that it gets compiled along Wesnoth, hence simplifying the engine and fixing once and for all all the future bugs related to C++/Lua interactions. The major downside is obviously that, if a new security breach appears in Lua itself, someone will have to grab the fix and apply it to Wesnoth. It is a real downside, and it is the main reason why it took me more than one year to finally decide on it. But I no longer consider it to be a blocker, and to explain that, I will tell a bit of Lua history, sorry. Lua 5.0 was released in 2003. In 2006, Lua 5.1 was released. From a user point of view, the main change was the module system, which is disabled in Wesnoth. So the language itself is quite stable and the code used nowadays for Wesnoth would work almost unmodified with a 2003 compiler. Now, what about the security issues? The last bugfix release was Lua 5.1.4 in 2008. Six bugs have been fixed since then, I have imported the fixes for these bugs as well. As far as I can tell, neither the .deb nor .rpm packages contain these additional fixes. Therefore, if the import had happened two years and nobody had taken care of it since then, Wesnoth wouldn't be less secure than the major distributions now. So, while it is some work to go from time to time on http://www.lua.org/bugs.html and click on "patch", it isn't that much work in my opinion. Finally, I will state that embedding Lua is not that uncommon. For that matter, I will just quote Rhonda who did some research work on it: (11:31:26) Rhonda: monotone, nmap, ocropus, enigma, freeciv, spring also do embed lua. (11:31:51) Rhonda: enigma for the same reason stated, with requiring lua built with c++ Best regards, Guillaume _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
