* Kees Cook <email address hidden> [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