Monkey-patching has multiple problems. The biggest problem for a security
fix like this is that it's way too easy to forget to re-apply when we
update Lua to a newer version.
Instead, we now have the implementation of load() under our control and can
update Lua without risk of reintroducing CVE-2018-1999023.
This could otherwise be used to escape the lua sandbox, as described in
multiple sources. For example one can use it to reenable the os.execute
function to do shell commands
The affected functions were
load,loadstring,wesnoth.dofile,wesnoth.require and various places in the
wesnoth source where lua chunks were loaded for example by the ai code.
This commit also changes the lua source to change luas load (which is
the same as loadstring), alternatively we could add a wrapper around the
original load function that always passes "t" as third parameter, i went
this way mostly because it was easier to implement, but also because i
was not 100% sure that is is impossible to query the upvalues of a
function via lua (wesnoth disables debug.getupvalue but still).
There is also an occurance in the application_lua_kernel that was not fixed
because i assumed that umc cannot contian application lua scipts.
As further security measure we might want to disable printing the function
adress in luas tostring for c functions, this cannot be exploited by itself
but it can be used to defeat ASLR in some cases.
Before:
20180724 17:21:37 error gui/layout: Failed to fit vertical list to requested rect; expected bottom edge was 277
20180724 17:21:37 error gui/layout: , actual bottom edge was 195
20180724 17:21:37 error gui/layout: (top edge is 113)
After:
20180724 17:34:30 error gui/layout: Failed to fit vertical list to requested rect; expected bottom edge was 277, actual bottom edge was 195 (top edge is 113)
This allows the sorting logic top be shared between the sidebar and the
unit preview pane. It also means that we no longer need to create a lambda
to sort them.
I also refactored the generation of movement cost data in help. In
particular, we're no longer extracting the struct to named local variables.
Also moved the string_map alias into the GUI2 namespace and renamed it widget_item.
It's the same as utils::string_map, but this makes its purpose clearer.
Unlike other widgets where `this` is the event target, the tree nodes fire the event
with the tree widget itself as the target.
I had added a fire-event call in f97dc8ae12, but with
the target as the node. I don't think there was any way that would have worked...
changed.
Child nodes were still managed with unique_ptrs in 1.14, so we couldn't use make_unique
there. Child nodes are now managed with shared_ptrs here on master.
Regression from commit 36e9290.
As @gfgtdf pointed out in the bug report, because old_player was a
reference to the shared_ptr, resetting the shared_ptr in sides_ also
changed old_player, and thus 'the player lost his last side' check never
passed.
Thanks to @gfgtdf for figuring out the cause.
gui/widgets/settings.hpp was rendered unnecessary in almost all dialog and widget files
as of 6759f41b1e, since it was no longer needed to implement
the internal functions wrapped by the REGISTER_DIALOG and REGISTER_WIDGET macros. Those
were register_window() and register_widget(), respectively.
In the case in bug #3321, damage prediction code somehow receives a
combatant whose probability to be slowed is very close to one of those
values but not quite it. I couldn't figure out how it's possible because
only damage prediction code itself is supposed to emit slow probabilities,
and it's not producing such a probability in this case.
Without more information, I'm simply fixing the bug by force. If the
probability is in the problematic area, we simply round it to 0 or 1. This
way such probabilities are impossible later on when we try to scale the HP
distributions so that they add to 1.
Fixes#3321.
Fixing the lack of stars on the remote client when sending a team/observer message.
This commit didn't modify the necessary lines in replay.cpp:
6aa3b3b
(of which the chat_msg::chat_msg one has already been fixed)
Fixes#3119
This was never finished, is not maintained, suffers from a lack of features the "old" listbox
class now has, and seems (according to the logs) to be have been superceded by the pane widget.
At the very least, the pane widget seems to be what mordante was working with in his early
prototype of a new addon manager, and not this 2010 list class.
Need to sort out the problems with dispatching events to the HUD or the gamemap, respectively.
Disabling the HUD for now so it should be possible to interact with the map in case someone
wants to work on its rendering.
