Judging from https://git.gnome.org/browse/libxml2/log/ a slightly more recent version might prevent a few memory leaks, which most likely also don't directly affect us (but I'm not exactly sure what the few libxml2 functions we use call internally). So it might be nice to also include those when we are going for actually fixing those issues.

(Unrelated, but we might want to also update libraries for Windows.)

Executing section Default...
Executing section Source...
Executing section JS...
Executing section XML GUI...
Executing section Python...
Executing section Perl...

http://jw:8080/job/phabricator_lint/274/ for more details.

Build is green

Updating workspaces.
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!
Checking XML files...

http://jw:8080/job/phabricator/1675/ for more details.

In D699#27874, @leper wrote:

we might want to also update libraries for Windows

Someone might want to propose that in the staff meeting tomorrow whose goal is to determine CF.

In D699#27874, @leper wrote:

Judging from https://git.gnome.org/browse/libxml2/log/ a slightly more recent version might prevent a few memory leaks, which most likely also don't directly affect us (but I'm not exactly sure what the few libxml2 functions we use call internally). So it might be nice to also include those when we are going for actually fixing those issues.

How do we know though that there aren't random bugs in that by definition not stable snapshot or WIP grade commits?

(Unrelated, but we might want to also update libraries for Windows.)

Someone might want to propose that in the staff meeting tomorrow whose goal is to determine CF.

Transported the message.
Brief analysis of the current state of windows libraries at https://trac.wildfiregames.com/ticket/3004#comment:27
Not convinced that those exploits nor the one in this patch should be release blockers at this stage of the release. Seems unlikely that someone can do something with these vulns.
Do agree about the need to nurse the dlls at a time before feature freeze.

If the snapshot version in the patch should be updated to a more recent one due to a memory leak, then we should just go all the way to the most recent development snapshot it sounds:

In https://git.gnome.org/browse/libxml2/log/

17 hours	Heap-buffer-overflow read of size 1 in xmlFAParsePosCharGroupHEADmaster	David Kilzer	1	-1/+1
17 hours	Fix NULL pointer deref in xmlFAParseCharClassEsc	Nick Wellnhofer	1	-1/+2
17 hours	Fix infinite loops with push parser in recovery mode

Didn't really make me more confident that this is guaranteed to be a better option than using the most recent stable.

In D699#28346, @elexis wrote:

Committing the patch was discussed with Itms, but we are not convinced of doing so for several less significant reasons:

• Noone to test the patch properly and the library is less tested than the most recent stable release

Ah, the joys of supporting OS X. I'll take obscure *nix over that most of the time.

• The windows release won't be fixed either and that has a higher attack surface.

(Not that I care about any of those two, but [see below])

• Someone would have to craft a malicious map file that would have to download malicious code and talk people into downloading and installing it. Since maps can also contain code too, the attacker doesn't need the exploit to cause harm.

Probably, but there are ideas about having sort of automated map/mod sharing and unless we start caring about things like this I'll try to shoot those plans down before anyone gets a chance to defend those plans. Not that I care a lot, but at the point we start doing this I will have to show that I have got nothing to do with those releases.

But to be a little less alarmed, I did warn you of possible issues.

WFG should review and whitelist mod versions. Other mods should at most be accessible with a red warning message box with a red stop sign.

It was discussed on http://irclogs.wildfiregames.com/2017-07-05-QuakeNet-%230ad-dev.log

21:53 < echotangoecho> we can exploit arbitrary code execution vulnerabilities by specially crafted js
21:54 < echotangoecho> search for code execution vulnerabilities back to spidermonkey 38 -- there are lots
21:55 < echotangoecho> (ok, they are hard to find as most are listed under mozilla ff)

22:42 < Philip`> I think you need to consider what sources of data should be trusted (i.e. you assume they are non-malicious) and what are untrusted, and which libraries deal with each type of data
22:43 < Philip`> e.g. I think mods pretty much have to be trusted - it's futile to try to make the engine handle malicious mods safely, because the attack surface is massive, so you shouldn't even try
22:44 < Philip`> whereas data received from a game server over the network should be untrusted and should never be able to compromise the user's computer (which is still difficult to guarantee but kind of feasible)
22:45 < Philip`> (Mods can e.g. trivially crash the game by calling Engine.Crash() from a GUI script; it's totally not designed to run scripts securely)
22:45 < Philip`> (and so it's no worse if a malicious Collada file can crash the game)

and with Itms starting 17:40 in http://irclogs.wildfiregames.com/2017-07-06-QuakeNet-%230ad-dev.log