[python-committers] [Python-Dev] next beta

["Martin v. Löwis"]

> That's true of a certain class of bugs, probably mostly in the C code. 
> I think potential security bugs in Python code will be closer to
> "regular" bug fixes.

While that may be true, I think that are much more infrequent, because
many attack paths (such as memory overwrites leading to remote code
execution) just don't exist. In many cases, it's clear that it is the
application that uses the library in an insecure manner, so many
security fixes involving Python code will be in the applications, not
the library.

In fact, I only recall a single security-related bug fix of Python code,
advisory PSF-2005-001: XML-RPC would allow to invoke arbitrary Python
code. In fixing this, valid uses might have been broken, so the patch
added the allow_dotted_names attribute for such applications. Clearly,
quite some time went into designing a fix for this problem, much more
than for a regular bug fix. This is comparatively ok, since security
fixes for Python library code are so rare.

> I was thinking about preventing commits on the branch.  Most security
> fixes of the type you describe come in through the psrt, and they may
> even be embargoed.  For a closed branch, you'd open it for the security
> patches when the embargo is lifted, make the commits, then close it
> again.  That would at least be a very strong clue that the branch is
> closed :).

That would be fairly easy to do. If there is consensus what branches
are closed, I can come up with a pre-commit hook.

Regards,
Martin