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.

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

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.

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

...

...

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

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

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 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

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

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.

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

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.

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

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 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.