On Tue, Feb 2, 2010 at 8:08 PM, Barry Warsaw <barry@python.org> wrote:
I'm thinking about doing a Python 2.6.5 release soon. I've added the following dates to the Python release schedule Google calendar:
2009-03-01 Python 2.6.5 rc 1 2009-03-15 Python 2.6.5 final
This allows us to spend some time on 2.6.5 at Pycon if we want. Please let me know if you have any concerns about those dates.
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash? -- anatoly t.
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
I've changed this issue to release blocker. What are the other issues?
On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
I've changed this issue to release blocker. What are the other issues?
I've basically run a query to get all "crash" type issues for Python 2.6 http://bugs.python.org/issue?@search_text=&title=&@columns=title&id=&@columns=id&stage=&creation=&creator=&activity=&@columns=activity&@sort=activity&actor=&nosy=&type=1&components=&versions=1&dependencies=&assignee=&keywords=&priority=&@group=priority&status=1&@columns=status&resolution=&nosy_count=&message_count=&@pagesize=50&@startwith=0&@queryname=&@old-queryname=&@action=search There are 65 entries and among them I can additionally confirm: http://bugs.python.org/issue3720 http://bugs.python.org/issue7788 http://bugs.python.org/issue5765 -- anatoly t.
There are 65 entries and among them I can additionally confirm: http://bugs.python.org/issue3720 http://bugs.python.org/issue7788 http://bugs.python.org/issue5765
One of them is fixed and the other two are pathological cases. You can't really trigger them by mistake. Regards Antoine.
On Tue, Feb 9, 2010 at 06:45, anatoly techtonik <techtonik@gmail.com> wrote:
On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new
versions
that are known to crash?
I've changed this issue to release blocker. What are the other issues?
I've basically run a query to get all "crash" type issues for Python 2.6
There are 65 entries and among them I can additionally confirm: http://bugs.python.org/issue3720 http://bugs.python.org/issue7788 http://bugs.python.org/issue5765
-- anatoly t.
After taking a quick look, at least 14 of them were misreported as crashes.
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
I've changed this issue to release blocker. What are the other issues?
For a bug fix release, it should (IMO) be a release blocker *only* if this is a regression in the branch or some recent bug fix release over some earlier bug fix release. E.g. if 2.6.2 had broken something that worked in 2.6.1, it would be ok to delay 2.6.5. If 2.6.2 breaks in a case where all prior releases also broke, it would NOT be ok, IMO, to block 2.6.5 for that. There can always be a 2.6.6 release. Of course, if this gets fixed before the scheduled release of 2.6.5, anyway, that would be nice. Regards, Martin
Le mardi 09 février 2010 à 22:55 +0100, "Martin v. Löwis" a écrit :
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
I've changed this issue to release blocker. What are the other issues?
For a bug fix release, it should (IMO) be a release blocker *only* if this is a regression in the branch or some recent bug fix release over some earlier bug fix release.
As far as I remember, I think we have had release blockers which weren't regressions. Not that I strongly want to argue in favour of this one anyway. cheers Antoine.
I've changed this issue to release blocker. What are the other issues? For a bug fix release, it should (IMO) be a release blocker *only* if this is a regression in the branch or some recent bug fix release over some earlier bug fix release.
As far as I remember, I think we have had release blockers which weren't regressions.
Of course, the release manager can always declare anything a release blocker, so that may have been the reason (I don't recall the details). Also, on a feature release, many more kinds of blockers may exist (e.g. for features that aren't complete yet). It simply may also have been that nobody argued in favor of process. I know that I have, from time to time, unblocked release blockers because I thought that they shouldn't have blocked the release out of principle. IOW, I feel that release blockers should only be used if something really bad would happen that can be prevented by not releasing. If nothing actually gets worse by the release, the release shouldn't be blocked. Regards, Martin
Martin v. Löwis <martin <at> v.loewis.de> writes:
IOW, I feel that release blockers should only be used if something really bad would happen that can be prevented by not releasing. If nothing actually gets worse by the release, the release shouldn't be blocked.
I think most blocking bugs we've had had been existing for a long time, but had only been discovered or at least reported quite recently. Other blockers were also about features not yet implemented, or missing backports. So whether something would have "gone bad" is really in the eye of the beholder :) Regards Antoine.
Antoine Pitrou wrote:
Martin v. Löwis <martin <at> v.loewis.de> writes:
IOW, I feel that release blockers should only be used if something really bad would happen that can be prevented by not releasing. If nothing actually gets worse by the release, the release shouldn't be blocked.
I think most blocking bugs we've had had been existing for a long time, but had only been discovered or at least reported quite recently. Other blockers were also about features not yet implemented, or missing backports. So whether something would have "gone bad" is really in the eye of the beholder :)
Maybe I'm being pedantic, but I really think there should be more objective criteria for such things. We could set a policy that we don't want to release Python if there are known ways of crashing it, but I think that would be useless as it would mean that we can't make any releases for the next five years or so (because we all know of ways of crashing the VM that aren't fixed yet; when I run out of ideas, I just ask Armin Rigo :-). So the policy that I would suggest to follow instead is that known crashes (and other "serious" bugs, like incompatibilities, or failures to build) can block releases only if they are regressions, or if the release manager decides to make them release blockers. In particular, I think that requests for blocking a release should be accompanies with a promise from a committer to resolve the issue by some point in time. When that point has passed with the issue unresolved, the release manager should be free to unblock the release. Regards, Martin
Le mercredi 10 février 2010 à 05:26 +0100, "Martin v. Löwis" a écrit :
Maybe I'm being pedantic, but I really think there should be more objective criteria for such things.
Well we could try to find objective criteria but I'm not sure we'll find agreement on them.
We could set a policy that we don't want to release Python if there are known ways of crashing it, but I think that would be useless as it would mean that we can't make any releases for the next five years or so
It really boils down to what kind of crasher it is. When it is triggered by giving 24 instead of 23 as an argument to time.asctime() (i.e. a simple off-by-one error), it is more severe than a crasher which can only be triggered through artificially convoluted code.
So the policy that I would suggest to follow instead is that known crashes (and other "serious" bugs, like incompatibilities, or failures to build) can block releases only if they are regressions, or if the release manager decides to make them release blockers.
I disagree with the idea that the severity of a bug is correlated with it being a regression. If e.g. a critical security problem is found, it has to be corrected even though it may have been present for 5 years in the source. Besides, as Barry said, classifying a bug as blocker is also a good way to attract some attention on it. Other classifications, even "critical", don't have the same effect. Regards Antoine.
On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Besides, as Barry said, classifying a bug as blocker is also a good way to attract some attention on it. Other classifications, even "critical", don't have the same effect.
Unfortunately, not many people have privilege to change bug properties to attract attention to the issues. For example, this patch - http://bugs.python.org/issue7582 is ready to be committed, it is trivial, not a release blocker, but would be nice be released. How to make it evident if nobody except committers is able to add any keywords to the issue? I suspect that even committers do not receive this privilege automatically. -- anatoly t.
anatoly techtonik <techtonik <at> gmail.com> writes:
Unfortunately, not many people have privilege to change bug properties to attract attention to the issues. For example, this patch - http://bugs.python.org/issue7582 is ready to be committed, it is trivial, not a release blocker, but would be nice be released.
Well not every bug deserves special attention. The patch above is IMO low priority, since it's a minor addition to a script in the Tools directory... Not something which will make a big difference, and I'm being kind. :) As for setting keywords, there doesn't seem to be much you could have an authority to decide as a non-committer. You might think (and perhaps with good reason) that the patch is ready for commit into the SVN, but it's precisely a committer's job to decide that. (if you want to apply for commit rights, you can do so on this mailing-list; I cannot say if it could be accepted or not, since I haven't followed your contributions very closely. But given you don't even seem to be mentioned in the ACKS file the answer would probably be no at this point) Regards Antoine.
Antoine Pitrou wrote:
As for setting keywords, there doesn't seem to be much you could have an authority to decide as a non-committer. You might think (and perhaps with good reason) that the patch is ready for commit into the SVN, but it's precisely a committer's job to decide that.
There are actually a few folks with dev privileges on the tracker that don't have commit rights. They do a good job helping to kick things in the right direction (there are a few bugs on my list that wouldn't be there if the triage people hadn't added me to the nosy list... now I just need to actually do something about them all...) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Feb 10, 2010, at 01:57 PM, anatoly techtonik wrote:
Unfortunately, not many people have privilege to change bug properties to attract attention to the issues. For example, this patch - http://bugs.python.org/issue7582 is ready to be committed, it is trivial, not a release blocker, but would be nice be released. How to make it evident if nobody except committers is able to add any keywords to the issue? I suspect that even committers do not receive this privilege automatically.
You do exactly what you've done here: email python-dev and plead your case. This particular issue seems like a new feature so it's not appropriate for Python 2.6.5. -Barry
On Wed, 10 Feb 2010 13:57:31 +0200, anatoly techtonik <techtonik@gmail.com> wrote:
On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Besides, as Barry said, classifying a bug as blocker is also a good way to attract some attention on it. Other classifications, even "critical", don't have the same effect.
Unfortunately, not many people have privilege to change bug properties to attract attention to the issues. For example, this patch - http://bugs.python.org/issue7582 is ready to be committed, it is trivial, not a release blocker, but would be nice be released. How to make it evident if nobody except committers is able to add any keywords to the issue? I suspect that even committers do not receive this privilege automatically.
FYI, committers do (or at least should) have full privileges on the tracker. Other people can also get full privileges on the tracker without being committers, generally by participating helpfully in issue review and issue triage. We give out tracker privileges more easily than commit privileges, but we don't give them out willy nilly. So the concern someone expressed about issues getting set to release blocker "just" to attract attention isn't an issue in practice, it seems to me. If a committer or triage person sets an issue to release blocker it should mean that they think the release manager should make a decision about that issue before the next release. That decision may well be that it shouldn't be a blocker. I think that the logic here is that it is all well and good if the release manager has the time to review all critical issues pre-release, but since they may not, those with tracker privs can help sort through the clutter by marking as release blockers those issues that the release manager (and others who are helping out) really *should* think about before the release goes out the door. I think that's what Barry was asking for when he said "feel free to mark things as release blockers". Of course there should be far fewer things getting set to release blocker for a maintenance release than for a new release even under this approach, and Martin's criteria are the ones that should be used by the release manager when deciding whether to *leave* an issue marked as a release blocker. But this is just my perception of the process, and I'm willing to work with whatever framework the community and release manager wants :) Anatoly, if you want particular issues to get attention, start reviewing issues on the tracker and helping move them along by commenting, and if your work is helpful you'll get noticed and offered tracker privs and be able to help even more. Related to this is the offer that Martin made and I have seconded: if someone wants attention paid to a particular issue, review five others and let Martin and/or I know and we'll review the issue you care about. -- R. David Murray www.bitdance.com
If a committer or triage person sets an issue to release blocker it should mean that they think the release manager should make a decision about that issue before the next release. That decision may well be that it shouldn't be a blocker.
I think it's (slightly) worse. For the release manager to override the triage, he has to study and understand the issue and then make the decision. In the past, that *did* cause delays in releases (though not in bug fix releases). So committers should be *fairly* conservative in declaring stuff release-critical. The release manager's time is too precious.
I think that the logic here is that it is all well and good if the release manager has the time to review all critical issues pre-release, but since they may not, those with tracker privs can help sort through the clutter by marking as release blockers those issues that the release manager (and others who are helping out) really *should* think about before the release goes out the door. I think that's what Barry was asking for when he said "feel free to mark things as release blockers".
That would require that Barry actually *can* judge the issue at hand. In the specific case, I would expect that Barry would defer the specifics of the Windows issue to Windows experts, and then listen to what they say. I'm personally split whether the proposed patch is correct (i.e. whether asctime really *can* be implemented in a cross-platform manner; any definite ruling on that would be welcome). In the past, we had rather taken approaches like disabling runtime assertions "locally"; not sure whether such approaches would work for asctime as well. In any case, I feel that the issue is not security-critical at all. People just don't pass out-of-range values to asctime, but instead typically pass the result of gmtime/localtime, which will not cause any problems. Regards, Martin
Martin v. Löwis wrote:
If a committer or triage person sets an issue to release blocker it should mean that they think the release manager should make a decision about that issue before the next release. That decision may well be that it shouldn't be a blocker.
I think it's (slightly) worse. For the release manager to override the triage, he has to study and understand the issue and then make the decision. In the past, that *did* cause delays in releases (though not in bug fix releases). So committers should be *fairly* conservative in declaring stuff release-critical. The release manager's time is too precious.
When I've kicked issues in the RM's direction for a decision, I've generally tried to make sure my last comment makes it clear exactly what decision I'm asking them to make. If I didn't want their opinion on some aspect of the issue I would just reject it, postpone it or commit it myself :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Feb 11, 2010, at 10:05 PM, Nick Coghlan wrote:
When I've kicked issues in the RM's direction for a decision, I've generally tried to make sure my last comment makes it clear exactly what decision I'm asking them to make.
Yes, this is an *excellent* point! -Barry
On Feb 10, 2010, at 11:46 PM, Martin v. Löwis wrote:
That would require that Barry actually *can* judge the issue at hand. In the specific case, I would expect that Barry would defer the specifics of the Windows issue to Windows experts, and then listen to what they say.
Yep, absolutely.
I'm personally split whether the proposed patch is correct (i.e. whether asctime really *can* be implemented in a cross-platform manner; any definite ruling on that would be welcome). In the past, we had rather taken approaches like disabling runtime assertions "locally"; not sure whether such approaches would work for asctime as well.
In any case, I feel that the issue is not security-critical at all. People just don't pass out-of-range values to asctime, but instead typically pass the result of gmtime/localtime, which will not cause any problems.
Unless other details come to light, I agree. This one isn't worth holding up the release for. -Barry
Le Thu, 11 Feb 2010 10:36:22 -0500, Barry Warsaw a écrit :
Unless other details come to light, I agree. This one isn't worth holding up the release for.
Ok, since everyone seems to agree on this, I've downgraded the priority of the issue. Thanks for an insightful discussion :-) cheers Antoine.
Antoine Pitrou writes:
Besides, as Barry said, classifying a bug as blocker is also a good way to attract some attention on it. Other classifications, even "critical", don't have the same effect.
If done for the sole purpose of attracting attention, it's no different from spam. Opinions will differ about what is and is not a blocker, and I'm sure your sense is as conservative as the next guy's. But really, let's at least be in the grey zone; "attracting attention" is not a consideration.
On Feb 9, 2010, at 5:20 PM, Martin v. Löwis wrote:
Of course, the release manager can always declare anything a release blocker, so that may have been the reason (I don't recall the details).
I should probably clarify my last statement. I will sometimes mark an issue "release blocker" because I'd really like it to be fixed for the next point release, or because we're very close to having an applicable patch. Think of it more as a reminder to address the issue before the next release is created. However, I have also knocked issues down from blocker if it's clear that we won't have a fix in time, and it meets the other criteria that Martin has laid out. So feel free to mark issues as release blockers for 2.6.5. That doesn't mean it will actually block the release. -Barry
On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote:
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
I've changed this issue to release blocker. What are the other issues?
For a bug fix release, it should (IMO) be a release blocker *only* if this is a regression in the branch or some recent bug fix release over some earlier bug fix release.
E.g. if 2.6.2 had broken something that worked in 2.6.1, it would be ok to delay 2.6.5. If 2.6.2 breaks in a case where all prior releases also broke, it would NOT be ok, IMO, to block 2.6.5 for that. There can always be a 2.6.6 release.
Of course, if this gets fixed before the scheduled release of 2.6.5, anyway, that would be nice.
I completely agree. Besides, unless we have volunteers to step up, create, review, and apply patches, it makes no sense to hold up releases. In the case of the first posted bug, we need a Windows core developer to test, bless and apply the patch. -Barry
On Tue, Feb 9, 2010 at 21:24, Barry Warsaw <barry@python.org> wrote:
On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote:
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
I've changed this issue to release blocker. What are the other issues?
For a bug fix release, it should (IMO) be a release blocker *only* if this is a regression in the branch or some recent bug fix release over some earlier bug fix release.
E.g. if 2.6.2 had broken something that worked in 2.6.1, it would be ok to delay 2.6.5. If 2.6.2 breaks in a case where all prior releases also broke, it would NOT be ok, IMO, to block 2.6.5 for that. There can always be a 2.6.6 release.
Of course, if this gets fixed before the scheduled release of 2.6.5, anyway, that would be nice.
I completely agree.
Ditto from me. -Brett
Besides, unless we have volunteers to step up, create, review, and apply patches, it makes no sense to hold up releases. In the case of the first posted bug, we need a Windows core developer to test, bless and apply the patch.
-Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
I've changed this issue to release blocker. What are the other issues?
For a bug fix release, it should (IMO) be a release blocker *only* if this is a regression in the branch or some recent bug fix release over some earlier bug fix release.
Is it possible to make exploits out of crashers? -- anatoly t.
On Feb 9, 2010, at 9:54 PM, anatoly techtonik wrote:
Is it possible to make exploits out of crashers?
The crashers involve creating convoluted python code, but then if you're in a position to execute arbitrary Python code, then you don't have to resort to any tricks to do something nasty within the scope of your user permissions. Raymond
anatoly techtonik <techtonik <at> gmail.com> writes:
Is it possible to make exploits out of crashers?
It depends which ones. If it's something like a buffer overflow or a memory management problem, it may be possible to exploit it through carefully crafted input (in order to make the interpreter execute arbitrary machine code). A security expert would be able to shed more light on this. Regards Antoine.
On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash? I've changed this issue to release blocker. What are the other issues? For a bug fix release, it should (IMO) be a release blocker *only* if
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : this is a regression in the branch or some recent bug fix release over some earlier bug fix release.
Is it possible to make exploits out of crashers?
It depends on the specific crasher. In Python, it depends on the application as well. In the specific issue you mentioned, it doesn't crash because of a memory overwrite, but because of a deliberate process shutdown in the C runtime. So you can't construct arbitrary code execution out of that. Regards, Martin
anatoly techtonik writes:
Is it possible to make exploits out of crashers?
Depends on how you define "exploit". If your definition includes denial of service, yes, crashing a server application would count. Privilege escalation is harder to achieve. The general answer is "yes", but each case is different, and requires expert analysis.
I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash?
As a general principle: yes, that's ok. We even distribute known crashers with every release. Regards, Martin
participants (10)
-
"Martin v. Löwis" -
anatoly techtonik -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Brian Curtin -
Nick Coghlan -
R. David Murray -
Raymond Hettinger -
Stephen J. Turnbull