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/)
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:
Giampaolo Rodola' wrote:
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/
On Jan 23, 2008 12:25 PM, Steve Holden <steve@holdenweb.com> wrote:
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/)
Guido van Rossum wrote:
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/
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.
On Jan 23, 2008 7:28 PM, ocean <ocean@m2.ccsnet.ne.jp> wrote:
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/)
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... 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))) n
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
From:
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test...
The errors are:
File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox .py",
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."""
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))
On 22-Jan-08, at 8:47 PM, Guido van Rossum wrote:
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
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:
Giampaolo Rodola' wrote:
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/
On Jan 23, 2008 12:25 PM, Steve Holden <steve@holdenweb.com> wrote:
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/)
Guido van Rossum wrote:
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/
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.
On Jan 23, 2008 7:28 PM, ocean <ocean@m2.ccsnet.ne.jp> wrote:
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/)
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... 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))) n
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
From:
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test...
The errors are:
File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox .py",
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."""
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))
On 22-Jan-08, at 8:47 PM, Guido van Rossum wrote:
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
participants (10)
-
"Martin v. Löwis" -
Brett Cannon -
Giampaolo Rodola' -
Guido van Rossum -
Mike Klaas -
Neal Norwitz -
ocean -
Stephen J. Turnbull -
Steve Holden -
Thomas Heller