I'm ok with any of those, or all. Agreed that some sort
of allocator for req and conn_recs makes sense, esp as
we look to http2 and the idea of slave conn_recs

> On Jan 9, 2015, at 3:48 PM, Jeff Trawick <traw...@gmail.com> wrote:
> 
> On Fri, Jan 9, 2015 at 3:23 PM, Joe Orton <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."
> 
> -- 
> Born in Roswell... married an alien...
> http://emptyhammock.com/
> 

Reply via email to