[Python-Dev] 2.5.2 release coming up
Guido van Rossum
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
> 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
> 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'
> 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
>> 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
>> 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
> 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
> 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.
>
from that.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
ocean
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
> 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"
>> 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
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
> 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
>
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
> "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
> 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