* Kees Cook <[email protected]> [2009-03-10 19:09:41 CET]: > Comparing the fixes that Debian performed[1], I think this patch may > additionally require fixes for CVE-2009-0366.
Not in this version because it doesn't support gzip compression, so the changes aren't that big. Additionally, the code has changed a fair bit through the gzip compression addition and I wasn't able to locate the specific code sections with some quick search. But given that the execution of arbitrary code on client machines is a fair bit more severe than this issue I think it's more than acceptable to _not_ delay the python fix any further. > Also, please follow the changelog format in the Security Update > Procedures[2], since that will make it easier for us to examine the > patches. I'm sorry, I'm no MOTU, I can't sign the Ubuntu CoC because with that I would claim to expect Mark to be perfect, so I haven't tried to dig further into Ubuntu practises. I just wanted to offer in a best-effort manner what could help you to get the problem fixed. If you are fine with letting the users vulnerable to arbitrary code execution that's fine with me. And I'm not completely sure why the style of the changelog should actually make it easier to examine the patch - but then, that might be just me. > I do have a worry that just ripping out Python is the wrong approach to > take with this bug, as that drops features as well. It drops a feature that is dropped in the upcoming 1.6 release and never really was used anywhere at all but only a single scenario in a single campaign (which was fixed with the update too, take a look at the changes that went into jaunty). All user created stuff that is available through the wesnoth addon server was checked, and given that the community is pretty tight this is a quite complete check. Furthermore, if you know a way to properly sandbox python, feel free to bring it up. The wesnoth team has quite some python evangelists on board but they were unable to find a way to sanely limit python. Additionally, it is discussed to replace this feature with a scripting language that is actually intended to be run in such an environment - so it might come back eventually (even if it wasn't really used ...). > However, in the light of upstream's response to the bug (they did the > same), I think it makes sense. Will there be AIs that no longer work > if this code is removed from wesnoth? > > [1] > http://packages.debian.org/changelogs/pool/main/w/wesnoth/current/changelog You might rather want to take a look of this changelog (the one that went into unstable, not experimental, and through that into jaunty): http://packages.debian.org/changelogs/pool/main/w/wesnoth/wesnoth_1.4.7-4/changelog Quoting from that changelog, on which most parts of the both patches are based: - Pull wesnoth-did-ai-fix patch from upstream svn r33013 to make it still work after above changes. I did like I was adviced, and I'm sorry that it doesn't please you enough, but I have done six uploads/patches for wesnoth in Debian, spoken to Secunia to answer their questions about the issue, coordinated with the wesnoth team directly, prepared these two patches (which you now consider incomplete...) to ease your work for a distribution that I can't upload to and propably won't be able to do so for a long time (see CoC issue above). If you don't have interest to get the issue fixed that's fine with me - I tried to do my best, if that's not enough, I'm sorry for that. Slightly disappointed, both from being exhausted and the delay in response. Rhonda -- Wesnoth security fixes https://bugs.launchpad.net/bugs/336396 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
