MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34.

Regards,
Nicolas

2005/7/29, Graham Dumpleton <[EMAIL PROTECTED]>:
Sorry, getting a bit overwhelmed with all these rapid changes in state
of things as bit busy today. Will probably will only know what is going
on when I look at latest code in repository. Then I'll probably pipe in
with some more pertinent comments about 3.2.

One report I would like to get some confirmation about is:

  http://issues.apache.org/jira/browse/MODPYTHON-34

This was about a potential security hole. Nicolas has indicated that
changes he had been working on which involved a different module
loader addressed it, but if various things are getting pushed to 3.3,
is then this addressed or not in what would make it to 3.2?

Since it was security related, just wanted to highlight it even if
exposure risk is low.

BTW, did anyone see an issue with my proposal for making the
req.path_info attribute writable. Ie.,

  http://issues.apache.org/jira/browse/MODPYTHON-67

I have been working on some code which would depend on such a
change and the code is of a nature that I think would be a nice
candidate for rolling back into the mod_python core. If path_info
was writable in 3.2, would allow people to experiment with the code
I am working on, or even turn it into a common project, without
needing to patch the mod_python source code.

I know Jim gave a +1 for path_info to be writable.

Graham

Jim Gallacher wrote ..
> Jim Gallacher wrote:
> > Gregory (Grisha) Trubetskoy wrote:
> >
> >>
> >> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
> >>
> >>> Note that there are 29 unscheduled issues :
> >>>
> >>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
> >>>
> >>>
> >>> Maybe some of them should be included in the 3.2 release ?
> >>
> >>
> >>
> >> My inclanation is to just release whatever we have, and mark it as a
> >> beta release. The last "true" release was 3.1.3 in Feb 2004, which
> >> makes it 18 months (if my math is correct)....
> >>
> >> Grisha
> >>
> >
> > I've either commited fixes or have fixes ready for 6 or 8 of those
> > issues. Also there some that don't apply to 3.2 (eg website or mailing
> > list issues). Must run right now but will make a list this evening of
> > issues which can be closed.
> >
> > Jim
> >
>
> Here is my list. I think you can close all of these JIRA issues except
> MODPYTHON-52.
>
> http://issues.apache.org/jira/browse/MODPYTHON-45
> Implement a file-based session manager
> Resolved but waiting for documentation. Working on it now - will commit
> in the next 12 hours.
>
> http://issues.apache.org/jira/browse/MODPYTHON-58
> _apache._global_lock results in segfault when index > number of mutexes
> Fix has been commited
>
> http://issues.apache.org/jira/browse/MODPYTHON-62
> local_ip and local_host in connection object returns remote_ip and
> remote_host instead
> This issue only applies to 3.1.4. It's already been fixed in 3.2.
>
> http://issues.apache.org/jira/browse/MODPYTHON-65
> 3.2 working version will not install on Mac OS X ( 10.3.7)
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-66
> install_dso target also tries to install Python code files
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-59
> Add get_session() method to request object
> Let's defer this to 3.3. I've changed current implementation to raise a
> NotImplemented error.
>
> Related to get_session, I've made a small change to Session.Session().
> It now checks PythonOption session for the default session type before
> using the hard coded default. For reasons that escape me I put this in
> a
> separate function, create_session(), but it really belongs in Session().
> This is useful outside of get_session, so I've kept the change for 3.2.
>
> Regards,
> Jim

Reply via email to