[Python-Dev] 2.5.2 release coming up

0 views
Skip to first unread message

Guido van Rossum

unread,
Jan 22, 2008, 11:47:02 PM1/22/08
to python-dev
While the exact release schedule for 2.5.2 is still up in the air, I
expect that it will be within a few weeks. This means that we need to
make sure that anything that should go into 2.5.2 goes in ASAP,
preferably this week. It also means that we should be very careful
what goes in though -- and we should be paying particular attention to
stability on all platforms! Fortunately it looks like quite a few 2.5
buildbots are green: http://python.org/dev/buildbot/2.5/

I propose that anything that ought to go into 2.5.2 (or should be
reviewed for suitability to go into it) should be marked "urgent" in
the tracker, *and* have its version set to (or include) "Python 2.5".

Also, *nothing* should go into the 2.4 branch any more *except*
important security patches. If we're doing a security release, it'll
most likely be a source-only release, and it will differ from 2.4.4
only in that it will have some new security patches defined.

A reminder: 2.5.2 should only get bugfixes, new features.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev2-garchive-22421%40googlegroups.com

Brett Cannon

unread,
Jan 22, 2008, 11:57:02 PM1/22/08
to Guido van Rossum, python-dev
On Jan 22, 2008 8:47 PM, Guido van Rossum <gu...@python.org> wrote:
> While the exact release schedule for 2.5.2 is still up in the air, I
> expect that it will be within a few weeks. This means that we need to
> make sure that anything that should go into 2.5.2 goes in ASAP,
> preferably this week. It also means that we should be very careful
> what goes in though -- and we should be paying particular attention to
> stability on all platforms! Fortunately it looks like quite a few 2.5
> buildbots are green: http://python.org/dev/buildbot/2.5/
>
> I propose that anything that ought to go into 2.5.2 (or should be
> reviewed for suitability to go into it) should be marked "urgent" in
> the tracker, *and* have its version set to (or include) "Python 2.5".
>
> Also, *nothing* should go into the 2.4 branch any more *except*
> important security patches. If we're doing a security release, it'll
> most likely be a source-only release, and it will differ from 2.4.4
> only in that it will have some new security patches defined.
>
> A reminder: 2.5.2 should only get bugfixes, new features.

If Guido felt like dragging the time machine out he would catch his
mistake and have that say "NO new features".

-Brett

Stephen J. Turnbull

unread,
Jan 23, 2008, 1:24:02 AM1/23/08
to Brett Cannon, Guido van Rossum, python-dev
Brett Cannon writes:
> On Jan 22, 2008 8:47 PM, Guido van Rossum <gu...@python.org> wrote:

> > A reminder: 2.5.2 should only get bugfixes, new features.
>
> If Guido felt like dragging the time machine out he would catch his
> mistake and have that say "NO new features".

What, nothing about "Read my lips"?

Giampaolo Rodola'

unread,
Jan 23, 2008, 2:21:37 PM1/23/08
to pytho...@python.org
> Also, *nothing* should go into the 2.4 branch any more *except*
> important security patches.

http://bugs.python.org/issue1745035
I guess this one should concern both 2.4 and 2.5 branches.

On 23 Gen, 05:47, "Guido van Rossum" <gu...@python.org> wrote:
> While the exact release schedule for 2.5.2 is still up in the air, I
> expect that it will be within a few weeks. This means that we need to
> make sure that anything that should go into 2.5.2 goes in ASAP,
> preferably this week. It also means that we should be very careful
> what goes in though -- and we should be paying particular attention to
> stability on all platforms! Fortunately it looks like quite a few 2.5
> buildbots are green:http://python.org/dev/buildbot/2.5/
>
> I propose that anything that ought to go into 2.5.2 (or should be
> reviewed for suitability to go into it) should be marked "urgent" in
> the tracker, *and* have its version set to (or include) "Python 2.5".
>
> Also, *nothing* should go into the 2.4 branch any more *except*
> important security patches. If we're doing a security release, it'll
> most likely be a source-only release, and it will differ from 2.4.4
> only in that it will have some new security patches defined.
>
> A reminder: 2.5.2 should only get bugfixes, new features.
>
> --
> --Guido van Rossum (home page:http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list

> Python-...@python.orghttp://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv...

Steve Holden

unread,
Jan 23, 2008, 3:25:46 PM1/23/08
to Giampaolo Rodola', pytho...@python.org
Giampaolo Rodola' wrote:
>> Also, *nothing* should go into the 2.4 branch any more *except*
>> important security patches.
^^^^^^^^^

>
> http://bugs.python.org/issue1745035
> I guess this one should concern both 2.4 and 2.5 branches.
>

Egregious though the error may be I can't myself see that a complete new
release is justified simply to include a four-line patch in a single
(not often-used?) module. If it were a buffer overflow it might be
different (but that would pretty much have to involve a C component).

Couldn't we just publicize the patch? I can't bring myself to believe
that 1745035 is really "important" enough.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Steve Holden

unread,
Jan 23, 2008, 3:25:46 PM1/23/08
to pytho...@python.org, pytho...@python.org
Giampaolo Rodola' wrote:
>> Also, *nothing* should go into the 2.4 branch any more *except*
>> important security patches.
^^^^^^^^^

>
> http://bugs.python.org/issue1745035
> I guess this one should concern both 2.4 and 2.5 branches.
>

Egregious though the error may be I can't myself see that a complete new

release is justified simply to include a four-line patch in a single
(not often-used?) module. If it were a buffer overflow it might be
different (but that would pretty much have to involve a C component).

Couldn't we just publicize the patch? I can't bring myself to believe
that 1745035 is really "important" enough.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

_______________________________________________

Guido van Rossum

unread,
Jan 23, 2008, 3:40:34 PM1/23/08
to Steve Holden, Giampaolo Rodola', pytho...@python.org
On Jan 23, 2008 12:25 PM, Steve Holden <st...@holdenweb.com> wrote:
> Giampaolo Rodola' wrote:
> >> Also, *nothing* should go into the 2.4 branch any more *except*
> >> important security patches.
> ^^^^^^^^^
> >
> > http://bugs.python.org/issue1745035
> > I guess this one should concern both 2.4 and 2.5 branches.
> >
>
> Egregious though the error may be I can't myself see that a complete new
> release is justified simply to include a four-line patch in a single
> (not often-used?) module. If it were a buffer overflow it might be
> different (but that would pretty much have to involve a C component).
>
> Couldn't we just publicize the patch? I can't bring myself to believe
> that 1745035 is really "important" enough.

It should go into 2.5 for sure. It should go into 2.4 at the
discretion of the release manager. We *are* considering a
pure-security-fixes source-only release of 2.4 (I wasn't 100% clear on
that in my first mail in this thread).

IMO DoS vulnerabilities are rarely worth getting excited about, unless
they have the potential of bringing down a significant portion of the
internet. This one doesn't.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

Steve Holden

unread,
Jan 23, 2008, 3:49:51 PM1/23/08
to Guido van Rossum, Giampaolo Rodola', pytho...@python.org
Guido van Rossum wrote:
> On Jan 23, 2008 12:25 PM, Steve Holden <st...@holdenweb.com> wrote:
>> Giampaolo Rodola' wrote:
>>>> Also, *nothing* should go into the 2.4 branch any more *except*
>>>> important security patches.
>> ^^^^^^^^^
>>> http://bugs.python.org/issue1745035
>>> I guess this one should concern both 2.4 and 2.5 branches.
>>>
>> Egregious though the error may be I can't myself see that a complete new
>> release is justified simply to include a four-line patch in a single
>> (not often-used?) module. If it were a buffer overflow it might be
>> different (but that would pretty much have to involve a C component).
>>
>> Couldn't we just publicize the patch? I can't bring myself to believe
>> that 1745035 is really "important" enough.
>
> It should go into 2.5 for sure. It should go into 2.4 at the
> discretion of the release manager. We *are* considering a
> pure-security-fixes source-only release of 2.4 (I wasn't 100% clear on
> that in my first mail in this thread).
>
> IMO DoS vulnerabilities are rarely worth getting excited about, unless
> they have the potential of bringing down a significant portion of the
> internet. This one doesn't.
>
Yes. There has to be a 2.5.2 release and there's no reason to exclude it
from that.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

ocean

unread,
Jan 23, 2008, 10:28:26 PM1/23/08
to Guido van Rossum, python-dev
Is threre any chance to fix this bug before releasing 2.5.2?
http://bugs.python.org/issue1736
It contains potential buffer overrun, I think this is somewhat important.
If multibyte support (CharNext) is not needed, I 'll rewrite the patch
gracefully.

Guido van Rossum

unread,
Jan 23, 2008, 11:09:39 PM1/23/08
to ocean, Martin v. Löwis, python-dev
On Jan 23, 2008 7:28 PM, ocean <oc...@m2.ccsnet.ne.jp> wrote:
> Is threre any chance to fix this bug before releasing 2.5.2?
> http://bugs.python.org/issue1736
> It contains potential buffer overrun, I think this is somewhat important.
> If multibyte support (CharNext) is not needed, I 'll rewrite the patch
> gracefully.

I'll leave that to MvL to decide; given that AFAIK msilib is only used
to build the Python installer I'm not sure it's worth defending
against malicious code -- it would be easier to simply remove it from
an installation if you have reason to believe you might be executing
malicious Python code.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

"Martin v. Löwis"

unread,
Jan 23, 2008, 11:40:32 PM1/23/08
to Guido van Rossum, python-dev
>> Is threre any chance to fix this bug before releasing 2.5.2?
>> http://bugs.python.org/issue1736
>> It contains potential buffer overrun, I think this is somewhat important.
>> If multibyte support (CharNext) is not needed, I 'll rewrite the patch
>> gracefully.
>
> I'll leave that to MvL to decide; given that AFAIK msilib is only used
> to build the Python installer I'm not sure it's worth defending
> against malicious code -- it would be easier to simply remove it from
> an installation if you have reason to believe you might be executing
> malicious Python code.
>

I'll look into it. msilib is used in distutils (for bdist_msi), so it
should get fixed.

Regards,
Martin

Neal Norwitz

unread,
Jan 24, 2008, 3:00:33 AM1/24/08
to Martin v. Löwis, Guido van Rossum, python-dev
We need to fix the Windows buildbots. 2 tests are currently failing
for 2.5.2: test_mailbox test_winreg

From:
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test/0

The errors are:

File "E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox.py",
line 522, in test_consistent_factory
msg2 = box.get_message(key)
File "E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
line 315, in get_message
subpath = self._lookup(key)
File "E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
line 484, in _lookup
raise KeyError('No message with key: %s' % key)
KeyError: 'No message with key: 1201127998.M194999P232Q203.buildbot'

and: test test_winreg failed -- Not the correct number of sub keys

There are several warnings from the tests that we should try to clean up:

lib\test\test_generators.py:1: DeprecationWarning: raising string
exceptions is deprecated
tutorial_tests = """
lib\zipfile.py:714: DeprecationWarning: struct integer overflow
masking is deprecated
0, 0, count, count, pos2 - pos1, -1, 0)
lib\zipfile.py:691: DeprecationWarning: struct integer overflow
masking is deprecated
header_offset)
lib\test\test_unicode_file.py:103: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
filename1==filename2
lib\shutil.py:36: UnicodeWarning: Unicode equal comparison failed to
convert both arguments to Unicode - interpreting them as being unequal
os.path.normcase(os.path.abspath(dst)))

Thomas Heller

unread,
Jan 24, 2008, 5:44:01 AM1/24/08
to pytho...@python.org
Neal Norwitz schrieb:

> We need to fix the Windows buildbots. 2 tests are currently failing
> for 2.5.2: test_mailbox test_winreg

The test_winreg failure is a funny one:

The py3k test_winreg fails because of a bug in the test itself; I fixed
this in rev. 60236. The failing test leaves a key in the registry that
make the trunk and release25-maint tests also fail.

I have manually removed the offending key in the registry on the x86 XP-3
buildbot; we'll see if it works now.

The real solution, however, would be to change all the test_winreg tests
to remove the test-key completely before and after their test. But I'll
leave this to someone else.

Thomas

ocean

unread,
Jan 24, 2008, 6:07:54 AM1/24/08
to Neal Norwitz, Martin v. Löwis, Guido van Rossum, python-dev
> From:
>
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test/0
>
> The errors are:
>
> File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox
.py",
> line 522, in test_consistent_factory
> msg2 = box.get_message(key)
> File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
> line 315, in get_message
> subpath = self._lookup(key)
> File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\mailbox.py",
> line 484, in _lookup
> raise KeyError('No message with key: %s' % key)
> KeyError: 'No message with key: 1201127998.M194999P232Q203.buildbot'

I did quick investigation on this error.

After self._refresh() (line 480 in _loopkup - Lib/mailbox.py) runs,
self._toc contains key like this.
1201171711.M848000P1176Q16.whiterab-c2znlh!2,FR
Please look at exclamation mark. Probably this is not intended on most
platforms like Unix.
It should be ":" colon.

But on windows, ":" is special letter after drive letter. (ex:
"C:/Winnt/foo/bar")
So I imagine open() or something converts ":" to "!" (valid character as
file name).

After I applied following experimental patch, test_mailbox.py run
successfully on windows.

Index: Lib/mailbox.py
===================================================================
--- Lib/mailbox.py (revision 60233)
+++ Lib/mailbox.py (working copy)
@@ -223,7 +223,8 @@
class Maildir(Mailbox):
"""A qmail-style Maildir mailbox."""

- colon = ':'
+# colon = ':'
+ colon = "!"

def __init__(self, dirname, factory=rfc822.Message, create=True):
"""Initialize a Maildir instance."""

ocean

unread,
Jan 24, 2008, 6:49:44 AM1/24/08
to ocean, Neal Norwitz, Martin v. Löwis, Guido van Rossum, python-dev
> But on windows, ":" is special letter after drive letter. (ex:
> "C:/Winnt/foo/bar")
> So I imagine open() or something converts ":" to "!" (valid character as
> file name).

Sorry, I lied. :-(

open() didn't change ":", test_mailbox.py (TestMaildir.setUp) changed
self._box.colon to "!"

Otherwise, newly created mail box in test_consistent_factory 's "colon" is
":".
This mismatch causes error.

Following patch solves error, but I don't know if this is good solution.

Index: Lib/test/test_mailbox.py
===================================================================
--- Lib/test/test_mailbox.py (revision 60233)
+++ Lib/test/test_mailbox.py (working copy)
@@ -458,12 +458,11 @@

class TestMaildir(TestMailbox):

- _factory = lambda self, path, factory=None: mailbox.Maildir(path,
factory)
-
- def setUp(self):
- TestMailbox.setUp(self)
+ def _factory(self, path, factory=None):
+ box = mailbox.Maildir(path, factory)
if os.name in ('nt', 'os2') or sys.platform == 'cygwin':
- self._box.colon = '!'
+ box.colon = '!'
+ return box

def test_add_MM(self):
# Add a MaildirMessage instance
@@ -518,7 +517,7 @@
# Create new mailbox with
class FakeMessage(mailbox.MaildirMessage):
pass
- box = mailbox.Maildir(self._path, factory=FakeMessage)
+ box = self._factory(self._path, factory=FakeMessage)
msg2 = box.get_message(key)
self.assert_(isinstance(msg2, FakeMessage))

Mike Klaas

unread,
Jan 29, 2008, 7:08:30 PM1/29/08
to python-dev
On 22-Jan-08, at 8:47 PM, Guido van Rossum wrote:

> While the exact release schedule for 2.5.2 is still up in the air, I
> expect that it will be within a few weeks. This means that we need to
> make sure that anything that should go into 2.5.2 goes in ASAP,
> preferably this week. It also means that we should be very careful
> what goes in though -- and we should be paying particular attention to
> stability on all platforms! Fortunately it looks like quite a few 2.5
> buildbots are green: http://python.org/dev/buildbot/2.5/
>
> I propose that anything that ought to go into 2.5.2 (or should be
> reviewed for suitability to go into it) should be marked "urgent" in
> the tracker, *and* have its version set to (or include) "Python 2.5".

I'm not sure if it is particularly urgent because of the rarity of
occurrence, but I discovered a bug that causes httplib to hang
indefinitely given some rarely-occurring input in the wild. To
reproduce:

python -c 'import urllib2; urllib2.urlopen("http://
www.hunteros.com").read()'

WARNING: the page was tagged by one of our users and is definitely NSFW.

Again, it seems to occur very rarely, but the behaviour is quite
painful and the fix trivial (see http://bugs.python.org/issue1966).

Thanks,
-Mike

Reply all
Reply to author
Forward
0 new messages