Like @gfgtdf pointed out, loadstring() is still supported by Lua in the
name of backwards compatibility, even though it was deprecated in Lua 5.2
and is no longer mentioned in Lua manual. Thus, as of committing this it's
actually possible to load Lua bytecode.
Let's unit test this to ensure that we don't reintroduce this
vulnerability.
this test whether we succesfully prevent the exceution and parsing of
precompiled lua chunks, which can be used to break the lua sandbox.
This test does not cover all affected functions in particular not the ai
code that loads lua chunks.
The test changes the default facet, which takes effect only if no other
facet takes priority. Thus, in turns 7 and 8, the test should expect attack
depth of 7, not 8.
Thanks to @CelticMinstrel for help.
Several keys were either missing or misnamed in the formula view.
These have been changed to match the Lua and WML names for the keys.
This affects canrecruit, moves, and max_moves, as well as status.
In addition, a large number of keys were missing entirely from the formula view.
Most of these keys have now been added and can be accessed from formulas.
A few that have little use in filters (such as image_mods or profile) are still missing.
The Lua view missed a few keys that the formula view did provide.
Although these could in principle have been obtained by using the special __cfg key,
they have now been added to the Lua view anyway.
And related commits.
This reverts commit 545253ec2b.
This reverts commit 1215f65eb8.
This reverts commit 11664f4024.
This reverts commit e948df3424.
This reverts commit 3781e7839f.
This commits were reverted to exclude them from wesnoth 1.13.2 release because:
1) We are still unsure about the best name oftthese attributes
2) This breaks multiple campaigns, including LoW and the tutorial.
Feel free to revert this revert after 1.13.2 when thse issues can be solved..
(With unit tests to back it up!)
- Fixes [for]step=0
- Fixes [for]start,stop=0,0
- Fixes [for]start,end,step=0,1,-1
- Probably fixes several other things too
This explains (in the log) why a WML conditional has failed (or succeeded). Currently it is fairly basic, looping through and/or/not and printing out the specific conditional tag that failed as well as, for [variable], the current content of the variable.
It's used in the WML unit tests system, but could also be useful for debugging.
This commit also fixes an issue with passing multiple -a arguments to run_wml_tests.
