Okay, I screwed up that analysis a bit. It is APR 1.X to 2.X which is the
issue and I can fix by having:
#if APR_MAJOR_VERSION < 2
#include "apr_support.h"
#endif
The specific code was:
#if APR_MAJOR_VERSION < 2
rv = apr_wait_for_io_or_timeout(NULL, sock, 0);
#else
rv = apr_socket_wait(sock, APR_WAIT_WRITE);
#endif
Either way, a minor tweak to mod_wsgi code.
Graham
On 10 January 2015 at 14:28, Graham Dumpleton <grah...@apache.org> wrote:
> FWIW, there is potentially another issue for mod_wsgi coming up as well.
> Seems that I was using an APR function which was tagged as internal and in
> trunk of APR the header file that function is defined in is no longer
> installed, or at least when within srclib of httpd, thus mod_wsgi will no
> longer build against APR trunk. Luckily this function was only used in some
> old dead code for Apache 1.3 and support for it has been dropped, so I can
> remove the dependency. Will still require an update to mod_wsgi to ensure
> that it can compile with latest APR. I am not sure if there is an intention
> to update APR soon as well as httpd.
>
> Graham
>
> On 10 January 2015 at 09:04, Graham Dumpleton <grah...@apache.org> wrote:
>
>> Thanks for the heads up and I appreciate very much the steps you are
>> taking to limit possible affects.
>>
>> What I will do is the following:
>>
>> 1. Verify that recompiling mod_wsgi is actually sufficient given than my
>> direct use of request_rec isn't going to populate the extra fields and they
>> will remain NULL still. As trailers shouldn't be expected in context the
>> request_rec is being used directly by mod_wsgi those attributes shouldn't
>> be touched, but if that is the case, why would it be crashing without
>> recompilation happening. So need to also actually verify whether it can't
>> limp on as is for now if it isn't crashing.
>>
>> 2. Publicise upcoming problem on my blog, mod_wsgi mailing list and doc
>> sites and repo.
>>
>> 3. As a hack to try and ease the transition for anyone compiling from
>> source code themselves, make a quick patch release of mod_wsgi which pads
>> the size of request_rec when it is allocated, with at least 2 * size of a
>> pointer. This way people can recompile this patched mod_wsgi now in advance
>> and they shouldn't have an issue when the httpd binaries themselves are
>> updated.
>>
>> 4. Work on more permanent solution. The possibility of API functions for
>> creating the structures has been suggested but not ideal as it is catering
>> for an obscure case where mod_wsgi may be the only transgressor. I have
>> contemplated doing away with using the request_rec in the mod_wsgi daemon
>> mode, but it was attractive for a few reasons. I will need to reassess how
>> much I do need it and whether I can eliminate it and find other ways to do
>> the things I was dependent on it for. One of the main things from memory
>> was actually related to logging, so it may be possible to do away with it.
>>
>> Thanks again for giving consideration for the problem I have caused.
>>
>> Graham
>>
>>
>> On 10 January 2015 at 07:55, Ruediger Pluem <rpl...@apache.org> wrote:
>>
>>>
>>>
>>> On 01/09/2015 09:48 PM, Jeff Trawick wrote:
>>> > On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <jor...@redhat.com <mailto:
>>> jor...@redhat.com>> wrote:
>>> >
>>> > Since Jim is talking 2.4.11, I should report this now. We
>>> discovered
>>> > this week in Fedora: mod_wsgi does some interesting things in
>>> daemon
>>> > mode, notably that it allocates a request_rec internally which
>>> ends up
>>> > getting used by httpd.
>>> >
>>> > Reason is, the fix for CVE-2013-5704 extends the request_rec:
>>> >
>>> > http://svn.apache.org/r1619884
>>> >
>>> > A mod_wsgi built against <= 2.4.10 will allocate a request_rec
>>> using the
>>> > old, smaller "wrong" size, and hence, if such a build is used with
>>> >=
>>> > 2.4.11, it passes in the wrong-sized request_rec and that breaks
>>> later
>>> > when httpd tries to access r->trailers_*.
>>> >
>>> > It's one of those fuzzy boundaries in the API, you can argue
>>> mod_wsgi is
>>> > wrong, but, I could argue it back; the struct *is* public, not got
>>> a
>>> > strong opinion on this personally.
>>> >
>>> > Either way, the fix for CVE-2013-5704 ends up breaking backwards
>>> > compatibility with existing 2.4.x builds of mod_wsgi, which is
>>> kind of
>>> > Bad. I don't have a good proposal for how to fix or avoid this.
>>> Worst
>>> > case, we make clear the mod_wsgi case is API/ABI abuse and warn
>>> binary
>>> > distributors they have to handle this by rebuilding.
>>> >
>>> > Regards, Joe
>>> >
>>> >
>>> > * One-time only: Make clear in announcement that mod_wsgi has to be
>>> rebuilt.
>>> > * Add helper functions to allocate a request_rec, conn_rec,
>>> server_rec. It doesn't solve all possible problems of
>>> > course but can drastically reduce the frequency of needing to
>>> recompile a module that needs to do such things.
>>> > * Module authors who allocate structures generally created by httpd
>>> own the monitoring and announcement, or should just
>>> > document "You must recompile this module every time you update httpd."
>>> >
>>>
>>> +1
>>>
>>> Regards
>>>
>>> Rüdiger
>>>
>>>
>>
>
