Henri Yandell | 17 Jul 08:48
Picon
Favicon
Gravatar

Quetzalcoatl/mod_python retirement

A heads up for the Quetzalcoalt + mod_python user community that the
Quetzalcoatl project has
been 'moved to the Attic'. This means that the Quetzalcoatl developers (more
formally its Project Management Committee) have voted to retire Quetzalcoatl
and move the responsibility for its oversight over to the Attic project.

Loosely speaking this means that the projects resources will be moved to a
read-only state.

You can read more about the Apache Attic and the process of moving to the
Attic at http://attic.apache.org.

You can follow this process in JIRA:

  https://issues.apache.org/jira/browse/ATTIC-67

Thanks,

Hen on behalf of Quetzalcoatl + the Attic.

Forest (JIRA | 28 May 00:23
Picon
Favicon

Created: (MODPYTHON-257) md5 module is deprecated; use hashlib instead

md5 module is deprecated; use hashlib instead
---------------------------------------------

                 Key: MODPYTHON-257
                 URL: https://issues.apache.org/jira/browse/MODPYTHON-257
             Project: mod_python
          Issue Type: Bug
    Affects Versions: 3.3.1
         Environment: ubuntu linux / python 2.6
            Reporter: Forest

mod_python is spewing a lot of log spam:

[Thu May 27 15:08:00 2010] [error] /usr/lib/python2.6/dist-packages/mod_python/importer.py:32:
DeprecationWarning: the md5 module is deprecated; use hashlib instead

Anders Blomdell | 5 Mar 09:59
Picon
Picon
Gravatar

Mod_python and unicode

Would it make sense to switch mod_python to always use unicode, as it is now,
publisher supports unicode content, but req.write and FieldList does use
bytestrings.

/Anders

Picon
Favicon

Created: (MODPYTHON-256) util.FieldStorage __setitem__/__delitem__ might affect wrong field

util.FieldStorage __setitem__/__delitem__ might affect wrong field
------------------------------------------------------------------

                 Key: MODPYTHON-256
                 URL: https://issues.apache.org/jira/browse/MODPYTHON-256
             Project: mod_python
          Issue Type: Bug
          Components: core
    Affects Versions: 3.3.1
         Environment: Any
            Reporter: Anders Blomdell

When a FieldStorage has two (or more) Filed instances with the same value but
different names, the behaviour of programs like this is (more or less) undefined:

  fs = util.FieldStorage(req)
  fs['id1'] = 'New value'
  del fs['id2']

The reason for the undefinedness, is this code in __delitem__ (and the similar
in __setitem__):

        table = self.list.table()
        values = table[key]
        for value in values:
            self.list.remove(value)

What happens is that the self.list.remove(value) will remove the first field
with a matching value, regardless of that fields name. Here is an example from
real life:
(Continue reading)

Anders Blomdell | 1 Mar 12:34
Picon
Picon
Gravatar

Bizarre behaviour in util.FieldStorage

Hi,

When a FieldStorage has two (or more) Filed instances with the same value but
different names, the behaviour of programs like this is (more or less) undefined:

  fs = util.FieldStorage(req)
  fs['id1'] = 'New value'
  del fs['id2']

The reason for the undefinedness, is this code in __delitem__ (and the similar
in __setitem__):

        table = self.list.table()
        values = table[key]
        for value in values:
            self.list.remove(value)

What happens is that the self.list.remove(value) will remove the first field
with a matching value, regardless of that fields name. Here is an example from
real life:

    form.clear()
    form['id1'] = 'x'
    form['id2'] = 'x'
    form['id3'] = 'x'
    # Form now contains {'id2': [Field('id2', 'x')],
    #                    'id3': [Field('id3', 'x')],
    #                    'id1': [Field('id1', 'x')]}
    form['id2'] = 'y'
    # Form now contains {'id2': [Field('id2', 'x'), Field('id2', 'y')],
(Continue reading)

VanL | 29 Dec 18:32
Picon
Gravatar

PyCon Early Bird is Ending Soon!

Do you have a year-end hole in your training budget? Or will the
improved economy let you finally attend a work conference? Come to sunny
and warm Atlanta in February for PyCon 2010. Early bird registration
ends on January 6.

Register: https://us.pycon.org/2010/register/

See the talks: http://us.pycon.org/2010/conference/talks/
Get trained at a tutorial:  http://us.pycon.org/2010/tutorials/

Also see the five (or more!) talks that people can't miss at PyCon:

PyOraGeek: PyCon pre-favorites
<http://catherinedevlin.blogspot.com/2009/11/pycon-pre-favorites.html>

Pyright: PyCon pre-favorites, the Carl T. edition:
<http://pyright.blogspot.com/2009/11/pycon-2010-pre-favorites-carl-t-edition.html>

Aftermarket Pipes: Five Pycon 2010 Talks I Need to See:
<http://apipes.blogspot.com/2009/12/five-pycon-2010-talks-i-need-to-see.html>

Jessenoller.com: PyCon 2010: Talks I want to see:
<http://jessenoller.com/2009/12/06/pycon-2010-talks-i-want-to-see-keynotes-registration-open/>

The Third Bit: Five PyCon Talks I Want To See:
<http://pyre.third-bit.com/blog/archives/3364.html>

See you at PyCon!

Register: https://us.pycon.org/2010/register/
(Continue reading)

Picon
Favicon

Commented: (MODPYTHON-235) Memory leaks in main Apache process when doing 'restart' or 'graceful'.


    [
https://issues.apache.org/jira/browse/MODPYTHON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768547#action_12768547
] 

Michael P. Soulier commented on MODPYTHON-235:
----------------------------------------------

Is anyone planning to fix this issue? It's hitting a product that I work on that performs graceful restarts
on apache regularly. 

If the solution above works, would the fix not be simple? This issue is 2 years old. 

> Memory leaks in main Apache process when doing 'restart' or 'graceful'.
> -----------------------------------------------------------------------
>
>                 Key: MODPYTHON-235
>                 URL: https://issues.apache.org/jira/browse/MODPYTHON-235
>             Project: mod_python
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.3.1
>            Reporter: Graham Dumpleton
>
> As raised in thread:
>   http://www.modpython.org/pipermail/mod_python/2007-June/023926.html
> it looks like mod_python exhibits memory leaks in the main Apache process when a 'restart' or 'graceful'
is done. Ie., when only child process are killed off and restarted rather than whole Apache being stopped.
> The poster though seems to be of opinion that it only happens when certain auth modules are loaded, which
makes the behaviour somewhat odd if true. One would expect it simply to always leak rather than being
(Continue reading)

Brian Martin (JIRA | 10 Oct 01:48
Picon
Favicon

Commented: (MODPYTHON-135) [SECURITY] A Security Issue with FileSession in 3.2.7


    [
https://issues.apache.org/jira/browse/MODPYTHON-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764257#action_12764257
] 

Brian Martin commented on MODPYTHON-135:
----------------------------------------

CVE-2006-1095

> [SECURITY] A Security Issue with FileSession in 3.2.7
> -----------------------------------------------------
>
>                 Key: MODPYTHON-135
>                 URL: https://issues.apache.org/jira/browse/MODPYTHON-135
>             Project: mod_python
>          Issue Type: Bug
>          Components: session
>    Affects Versions: 3.2.7
>            Reporter: Graham Dumpleton
>            Assignee: Jim Gallacher
>             Fix For: 3.2.8, 3.3.1
>
>
> As announced on the mailing list:
>   http://www.modpython.org/pipermail/mod_python/2006-February/020284.html
> If you are using the recently released mod_python 3.2.7 please beware that a 
> security issue was discovered in the FileSession code.
> You are vulnerable only if you are using mod_python 3.2.7 AND you are using 
> FileSession to keep sessions. FileSession is new in 3.2.7 and is not enabled by 
(Continue reading)

Picon
Favicon

Created: (MODPYTHON-255) PythonInputFilter doesn't appear to work for chunked request content.

PythonInputFilter doesn't appear to work for chunked request content.
---------------------------------------------------------------------

                 Key: MODPYTHON-255
                 URL: https://issues.apache.org/jira/browse/MODPYTHON-255
             Project: mod_python
          Issue Type: Bug
          Components: core
    Affects Versions: 3.3.1
            Reporter: Graham Dumpleton

If PythonInputFilter is used to create an input filter, but content handler isn't actually mod_python but
another module which can handle chunked request content, and a request is sent with chunked request
content, then things just don't seem to work as one would expect.

For example, if use:

$ curl -d "abcdefghijklmnopqrstuvwxyz" http://home.dscpl.com.au/~grahamd/echo.wsgi --header
"Transfer-Encoding: chunked"

Where the .wsgi script is for mod_wsgi and is:

import StringIO

def application(environ, start_response):
    headers = []
    headers.append(('Content-type', 'text/plain'))

    start_response('200 OK', headers)

(Continue reading)

Picon
Favicon

Created: (MODPYTHON-254) Signed Sessions should use a salt and not rely on md5.

Signed Sessions should use a salt and not rely on md5.
------------------------------------------------------

                 Key: MODPYTHON-254
                 URL: https://issues.apache.org/jira/browse/MODPYTHON-254
             Project: mod_python
          Issue Type: Bug
          Components: session
    Affects Versions: 3.3.1
            Reporter: Grisha Trubetskoy

Sessions should generate a random salt when signing so that cookies are not vulnerable to dictionary
attacks. In general storage of any data in signed cookies should be discouraged in favor of storing the
session locally and only passing on a session id to the browser. Also sessions use default hmac, which in
turn defaults to MD5 signatures. We should probably move on to SHA given how weak MD5 has been shown to be.

Picon
Favicon

Created: (MODPYTHON-253) Thread local storage only lasts for life of a request.

Thread local storage only lasts for life of a request.
------------------------------------------------------

                 Key: MODPYTHON-253
                 URL: https://issues.apache.org/jira/browse/MODPYTHON-253
             Project: mod_python
          Issue Type: Bug
          Components: core
    Affects Versions: 3.3.1
            Reporter: Graham Dumpleton

The mod_python code creates a fresh Python thread state object for every request, with it being destroyed
at end of the request. This thread state object is where thread local storage is kept. As a result, thread
local storage isn't really thread local storage and is instead request local storage for that thread.
This can be detrimental to performance for any web framework which relies on being able to cache stuff in
thread local storage for use at any time in life time of the process. Worst case will see that data being
recreated on every request, which could cause excessive overhead on process/application if creating
the data is time consuming.


Gmane