Preparing for mod_wsgi 3.4.
Graham Dumpleton
manage to get a good block of time today to back port a lot of stuff
from the mod_wsgi 4.0 development version to the mod_wsgi 3.X branch
so can release the changes as mod_wsgi 3.4. That leaves just the more
experimental stuff in mod_wsgi 4.0.
Normally I would not use a minor version release to put out
substantial new features, but mod_wsgi 4.0 is going to drag on for a
while yet, so didn't have much choice if wanted to get an updated
version out with things like Python 3.2+ and Apache 2.4 support.
The cumulative list of all the stuff that will be in mod_wsgi 3.4 can
be found at:
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0304
Because I back ported the changes quite quickly, it can all do with
some good testing and needs to be checked against the main Python and
Apache versions still. I will make a release candidate tar ball to
make that a bit easier task rather than relying on people having to
use Mercurial to get it from the source code repository. Before that
though there are still a few new changes I am looking at to integrate.
These changes are:
1. Means of turning on hash seed randomisation with recent updates of
Python. I still have a few issues to sort out here. I was supplied a
patch, but it doesn't go far enough and deal adequately with issues
like upgrading patch levels of Python against a mod_wsgi compiled
against an older version. It also didn't allow hash seeding, only
randomisation.
2. Means in authentication handler defined by WSGIUserScript of
overriding the value of REMOTE_USER that is then in turn passed onto
the WSGI application.
3. Changes to WSGI environ variable naming restrictions, used when
passing through headers to allow % such that can use % encoded header
values to pass through with encoded UTF-8. See as discussed in
'http://groups.google.com/group/modwsgi/browse_thread/thread/676b4272221bc1f7/42c8e7e335f249c1'.
There have bound to have been a few other features people have
requested and although I will try and go back through email and
tickets so see any that could be done, if there was something you were
waiting on, then speak up now.
My next likely chance to do any more work on this will be next weekend
so you have till then to give me your wish list items or to give any
feedback on the current code if you are able to test it by grabbing it
from the source code repo.
Graham
Luke Macken
> 1. Means of turning on hash seed randomisation with recent updates of
> Python. I still have a few issues to sort out here. I was supplied a
> patch, but it doesn't go far enough and deal adequately with issues
> like upgrading patch levels of Python against a mod_wsgi compiled
> against an older version. It also didn't allow hash seeding, only
> randomisation.
Attached is a patch that solves both of these problems.
This creates a WSGIPythonHashSeed option, which gets set to the
PYTHONHASHSEED environment variable. This option accepts either 'random'
or seed values 0-4294967295.
Thoughts?
luke
Graham Dumpleton
Needs to be a bit more complicated than that I suspect.
Because it can be set to a specific seed, I don't believe you can make
the assumption that one should allow that environment variable to be
inherited by sub process as that would then affected any Python
programs you might run from the process.
What I was likely to do was to set the environment variable, but defer
doing that until just before Python interpreter initialised. Then
after interpreter initialised, unset the environment variable from C
process level. This does though still leave it with os.environ of the
main interpreter, so may have to be removed manually from that.
The other thing contending with is whether you allow this to be set
differently for different daemon process groups, or just once globally
for the whole Apache and mod_wsgi daemon processes.
Graham
Luke Macken
> On 17 April 2012 10:06, Luke Macken <lma...@redhat.com> wrote:
> > On Sun, Apr 15, 2012 at 08:02:58PM +1000, Graham Dumpleton wrote:
> >> 1. Means of turning on hash seed randomisation with recent updates of
> >> Python. I still have a few issues to sort out here. I was supplied a
> >> patch, but it doesn't go far enough and deal adequately with issues
> >> like upgrading patch levels of Python against a mod_wsgi compiled
> >> against an older version. It also didn't allow hash seeding, only
> >> randomisation.
> >
> > Attached is a patch that solves both of these problems.
> >
> > This creates a WSGIPythonHashSeed option, which gets set to the
> > PYTHONHASHSEED environment variable. This option accepts either 'random'
> > or seed values 0-4294967295.
> >
> > Thoughts?
>
> Needs to be a bit more complicated than that I suspect.
>
> Because it can be set to a specific seed, I don't believe you can make
> the assumption that one should allow that environment variable to be
> inherited by sub process as that would then affected any Python
> programs you might run from the process.
>
> What I was likely to do was to set the environment variable, but defer
> doing that until just before Python interpreter initialised. Then
> after interpreter initialised, unset the environment variable from C
> process level. This does though still leave it with os.environ of the
> main interpreter, so may have to be removed manually from that.
Attached is an updated patch that addresses both of these concerns.
It will now setenv right before Py_Initialize, and unsetenv right after.
It will also remove PYTHONHASHSEED from the os.environ when
newInterpreterObject is called. As for the WIN32 stuff, I'm just
guessing.
> The other thing contending with is whether you allow this to be set
> differently for different daemon process groups, or just once globally
> for the whole Apache and mod_wsgi daemon processes.
With my limited knowledge of the mod_wsgi internals, I'm not quite sure
how this would be done.
luke