[issue1284316] Win32: Security problem with default installation directory

[Jason R. Coombs]

Jason R. Coombs  added the comment:

For those installing Python 2.7, I share here for others the [Powershell 
module](https://www.dropbox.com/s/62m9easad0iakat/python.ps1?dl=0) I include in 
my profile. With this module loaded, `get-python-ver 2.7.14` installs Python 
2.7.14 64-bit to "C:\Program Files\Python27". Feel free to copy/adopt the 
routine if you're deploying more than a couple of installs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Steve Dower]

Steve Dower added the comment:

Changing the default install directory in a maintenance release is not okay.

Users who are concerned about security can change the install directory, and 
bugs that arise as a result will be considered on their own merits.

Alternatively, you can obtain Python 2.7 from one of the companies who maintain 
a distribution (such as Continuum Analytics). Some of them default to a secure 
install directory.

--
stage: test needed -> resolved
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Samuel Bronson]

Samuel Bronson added the comment:

Um, you know this still affects Python 2.7 right?

Yes, I realize that it's not going to be very practical to change the default 
installation path for 2.7, but that doesn't make the issue disappear, nor is 
that the only way to close the hole.

Which is to say, the 2.7 installer should be changed to tighten the permissions 
on the installation directory when doing an "all-users" install (even if the 
directory already exists, though in that case it might make sense for it to be 
optional).

(I suppose the same logic applies to any other version < 3.5 that's still 
getting security updates, too?)


P.S. Does this count as CVE-2012-5379, even though that was reported against 
ActiveState's distribution?

I'm pretty sure it's an instance of CWE-276 
, at any rate.

--
nosy: +SamB
versions: +Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Steve Dower]

Steve Dower added the comment:

Closing this as fixed, as the discussions I've had at PyCon have largely 
suggested that the fix I've implemented is good.

In short:
* the default (obvious) install will be per-user only into 
%LocalAppData%\Programs\Python\Python35 - fully modifiable by whoever installed 
it but inaccessible by other users
* the default location for an all-users install will be %ProgramFiles%\Python 
3.5 (with redirection for 32-bit processes) - fully modifiable by 
administrators and usable by all users

Obviously users can customize the install location to reduce security, but we 
can't prevent that.

--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Steve Dower]

Steve Dower added the comment:

I'll reassign this to me, as I'm looking into making Program Files the default 
location for 3.5.

I'd like to release at least some of the alphas with the change active by 
default (i.e. it's easy to select the old directory) to get broader feedback. 
So far I haven't encountered any trouble other than in pip (as is being 
discussed at https://github.com/pypa/pip/issues/1668).

If things don't work well in the early releases of 3.5 we can easily revert the 
change, though I suspect the main feedback is going to be about the amount of 
typing required. In that case, I'll look into hardening the permissions on the 
root directory as part of installation.

Unless some really bad scenarios arise, getting the legacy permissions will be 
opt-in. As 3.5 will be the first version with that change there shouldn't be 
any direct back-compat issues - we can't make a change like that in maintenance 
releases or even 3.4.

--
assignee: loewis - steve.dower
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Brian Curtin]

Changes by Brian Curtin br...@python.org:


--
nosy:  -brian.curtin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Mark Lawrence]

Mark Lawrence added the comment:

I'm concerned that 3.5 is creeping ever closer and I wouldn't like to see work 
done on the installer backed out at the 11th hour because there has been no 
agreement here.  Does this need a discussion on python-dev?  For that matter 
has there been one already that I've forgotten about?

--
nosy: +BreamoreBoy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Antoine Pitrou]

Antoine Pitrou added the comment:

Mark Lawrence, please stop acting like you are the project leader. If you want 
to make concrete contributions to Python, you're welcome. But we don't need 
your project management guidance.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Mark Lawrence]

Mark Lawrence added the comment:

Pardon me for breathing.  As you clearly don't like the way I work would you be 
so kind as to reopen the issues that I've helped close in the last few months.  
It might bugger the stats on the bug tracker but hey ho.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Georg Brandl]

Georg Brandl added the comment:

Nobody doubts that pinging old issues helps getting some of them closed. But 
messages like msg228480 sound a bit pretentious, that's what Antoine is 
referring to.

--
nosy: +georg.brandl

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Friedrich Spee von Langenfeld]

Friedrich Spee von Langenfeld added the comment:

As mentioned before, many packages can not handle paths with spaces. I suppose 
that it is because of lacking knowledge on how to prevent such bugs. What would 
you think? Should this piece of information be in our documentation? Or is it 
already there?

--
nosy: +Friedrich.Spee.von.Langenfeld

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Georg Brandl]

Georg Brandl added the comment:

 As mentioned before, many packages can not handle paths with spaces.

This is common knowledge, yet may not be true anymore.  See this recent 
python-dev thread:

https://mail.python.org/pipermail/python-dev/2014-September/136434.html

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[eryksun]

eryksun added the comment:

 As mentioned before, many packages can not handle paths with 
 spaces.

 This is common knowledge, yet may not be true anymore.  

Well, see issue 21699. pip 1.5.6 is still using distlib 0.1.8, so the 
executable wrappers it creates are broken when the path to python.exe contains 
spaces.

--
nosy: +eryksun

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Giampaolo Rodola']

Changes by Giampaolo Rodola' g.rod...@gmail.com:


--
nosy: +giampaolo.rodola
versions: +Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

If on one hand I agree that Python being in C:\PythonXX is not optimal for all 
the reasons which have been mentioned so far, changing such an old established 
aspect of the interpreter would be too much disruptive as a change.
To say one, being that on Windows 'python' is not recognized as a command, some 
folks rely on it simply living in C:\Python** and make that assumption into 
their scripts (I did exactly this in psutil: 
https://code.google.com/p/psutil/source/browse/make.bat?name=release-2.1.0#23).

I agree with what Martin says here: 
http://bugs.python.org/issue1284316#msg26236.
We should let Python live in C\:PythonXX and just fix permissions during 
installation so that when the installation completes C:\PythonXX will not be 
writable by limited users. 
If this introduces a performance issue because the pyd files cannot be created 
afterwards then simply create pyd files as part of the installation process 
(this should be done if install for all users option is checked).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Jason R. Coombs]

Jason R. Coombs added the comment:

I still disagree. If the preferable place for Python to be installed is not in 
the root (and I fervently feel so), then there could be a transitional approach 
to move it to the appropriate place, such as creating symbolic links from the 
legacy destinations (as an opt-out option).

Still, as Martin said, a change to the default install location would require a 
PEP that would have to address these concerns.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Steve Dower]

Changes by Steve Dower steve.do...@microsoft.com:


--
nosy: +steve.dower

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +tim.golden

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Ezio Melotti]

Changes by Ezio Melotti ezio.melo...@gmail.com:


--
versions: +Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Gynvael Coldwind]

Gynvael Coldwind gynv...@gmail.com added the comment:

(since Issue 10491 is superseded by this one, I'll reply here)

As I've said in issue 10491, in my opinion this is not a case of frustrating 
users because they have to elevate the console (I think they have to do that in 
case of UAC anyway), but a case of privilege escalation vulnerability on 
mutli-user Windows systems with Python installed globally (i.e. in the default 
installation directory).

Though I am aware there are not many such systems to begin with, I am pretty 
certain they do exist (think: servers at an University giving Python access to 
students, and not using *nix for some reason).
There are also non-multi-user systems with multiple accounts (think: production 
systems running stuff on different accounts), and this issue can be abused as 
one of many steps during an attack, after gaining shell access, but before 
gaining administrative rights.

I acknowledge your right to choose not to fix this issue due to usability 
issues, but in such case imo there should be an explicit message during the 
installation making the user aware of this insecurity.
The last months revealed issues like this in many applications and tools, and 
they have (mostly) been patched, so administrators might assume this was also 
fixed in Python (especially since this is known from 2005).

--
nosy: +Gynvael.Coldwind

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Fran Rogers]

Fran Rogers f...@dumetella.net added the comment:

I'd like to concur that Python should install to %ProgramFiles% by default. The 
root-directory default is particularly anomalous on 64-bit Windows, where you 
have separate 64- and 32-bit Program Files directories; if I have a Python 
installation in C:\Python26, is it amd64 Python or x86 Python? If I want to 
install both (since many packages don't yet support amd64), which one should I 
install to \Python26 and which should I rename?

As mel's post above (2005-11-15 11:39) points out, installing to C:\ is 
comparable to installing to /python2.6 on a Unix box; it's nonstandard, 
inelegant, and prone to ACL problems like the one this bug was opened for. If 
convenience on the command line (for non-power-users unfamiliar with %Path%) is 
the concern, a better solution would be a checkbox in the installer to add the 
new Python to the system %Path%.

--
nosy: +fran.rogers

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Mark Hammond]

Mark Hammond mhamm...@users.sourceforge.net added the comment:

Another consideration here will be how distutils will work in a python with 
restricted permissions - the pattern of just run 'setup.py install' will not 
work unless it is done from an elevated command-prompt.  As I expect this would 
frustrate people we'd need some story to address this.

My take is still that Python is a tool, not an app.  People writing an app they 
with to distribute using Python should include Python in their package (ie, not 
rely on an installed version) and these apps should conform with the guidelines.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

Note that Ezio and Flox have been improving the test suite and code to handle 
paths-with-spaces better.  Perhaps we will eventually get to the point where it 
is possible to fix this, although Tim's point about python being a 
CLI/scripting tool remains.

Or perhaps the permissions of the actual install directory could be changed at 
install time if the install is done by an administrator.

--
components: +Windows
nosy: +ezio.melotti, flox, michael.foord, r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Michael Foord]

Michael Foord mich...@voidspace.org.uk added the comment:

This is similar to an issue I reported to the security team (same underlying 
issue). My concern was that with an admin installed version of Python an 
arbitrary user can modify site.py, or create sitecustomize.py, and cause 
arbitrary code execution when the admin runs Python.

IMO an admin installed Python should require admin priveleges to write to the 
Python install directory. I think many users would find installing to Program 
Files a pain and it would break many scripts.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Brian Curtin]

Changes by Brian Curtin cur...@acm.org:


--
nosy: +brian.curtin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Jason R. Coombs]

Jason R. Coombs jar...@jaraco.com added the comment:

I personally make heavy use of the command line and continue to install python 
to %ProgramFiles%. I find the space in the pathname to be a non-issue. After 
%programfiles%\Python26 and %programfiles%\Python26\Scripts are added to the 
path, and .py is added to PATHEXT, everything behaves very well. I use cmd.exe 
and powershell, and both of these shells handle the spaces well enough, 
including supporting tab completion (so if one _does_ need to reference a path 
with a space in it, it's not even necessary to know what the syntax is).

With Python 3, support for version of Windows prior to XP (including DOS) has 
been deprecated, so it seems to me rather regressive to insist on DOS 8.3 
compatibility.

I concur that early on, I would struggle with the spaces if Python was 
installed to %programfiles%, but since about Python 2.3 or 2.4, I've had only 
the one problem with setuptools, and that has been fixed.

IMO, supporting installation to Program Files is not only the right thing to 
do, but it will make Python more robust.

On the other hand, I may be unaware of any use cases which are still 
problematic. Perhaps there are still many who always launch python using 
\python26\python. That command would then become \program 
files\python26\python. I find that to be a small price to pay for the gains in 
security and consistency (and compartmentalization).

Furthermore, a heavy command-line user is probably also a power user, and if 
typing C:\Program Files\Python26\Python is too onerous, I'm sure he can find 
a workaround, such as setting the path, creating hardlinks or symlinks, setting 
up aliases, etc.

I agree it's a shame the de-facto location for Programs on Windows isn't a more 
amenable name.

Personally, I always override the default installation directory, so it matters 
to me little what choice is made for the default, but on the whole, I believe 
users would be better off with Python in Program Files.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Michael Foord]

Michael Foord mich...@voidspace.org.uk added the comment:

I've tried installations of Python to Program Files in recent years (Python 2.4 
and 2.5) and found many scripts/tools unable to cope with the space in the 
path. I always ended up reinstalling. (Usually using sys.executable in 
conjunction with calling out to shell scripts.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

I propose that people in favor of changing the default install location write a 
PEP proposing that this be done.

Notice that this is independent of the issue at hand, which is about the ACLs 
on c:\pythonXY. I have tried fixing it, and failed so far.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Jason R. Coombs]

Jason R. Coombs jar...@jaraco.com added the comment:

Martin: Would it be sufficient to copy the ACLs from %programfiles%, or would 
it be better to hard-code the permissions from %programfiles% from a known 
standard configuration? Is it known if the ACLs on %programfiles% in WinXP 
differ from later platforms? What difficulty have you encountered?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

 Martin: Would it be sufficient to copy the ACLs from %programfiles%,
 or would it be better to hard-code the permissions from
 %programfiles% from a known standard configuration? Is it known if
 the ACLs on %programfiles% in WinXP differ from later platforms? What
 difficulty have you encountered?

I can only answer the last question: I tried using the ACL features in
MSI (i.e. with the LockPermissions table), and couldn't get that to work.

Personally, I would think that restricting write access to the user
performing the installation should be good enough.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Mark Hammond]

Changes by Mark Hammond [EMAIL PROTECTED]:


--
nosy: +mhammond

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Jason R. Coombs]

Jason R. Coombs [EMAIL PROTECTED] added the comment:

+1 on using Program Files by default.

In addition to the points mentioned above, there are other considerations.

In 64-bit platforms (Windows XP x64 and Vista 64-bit), programs are
segmented by their binary compatibility (C:\Program Files and C:\Program
Files (x86)).  Installing Python to the proper program directory helps
keep it organized as to it's binary compatibility.

Additionally, I often run several version of Python side-by-side, and
having these clutter my root directory is simply unacceptable.

I've been running Python from C:\Program Files for years, and I have
encountered problems, even including the recent setuptools bug, but for
the most part, these issues have been worked out.  I add C:\Program
Files\Python and c:\Program Files\Python\Scripts to my path, and things
work well.  I would think that since only a few issues remain, if Python
is moved to the standard location, any remaining issues can be ironed out.

--
nosy: +jaraco

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1284316
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1284316] Win32: Security problem with default installation directory

[Carl Karsten]

Carl Karsten added the comment:

Another reason to fix: perception.  installing to the root looks like a
hack.  Installing to the proper place* looks professional.  

As for it being hard to type, either add it to PATH or put a .bat file
in the path.  I think vista even supports some sort of symlink, so that
might be best.

As for easy_install.exe and others breaking when they hit a space, They
should be fixed too.  avoiding fixing them means people who try to force
the installer to do the right thing end up with a headache, which is evil.

* proper place isn't always C:\Program Files - the installer builder
should have an option to determine what it should be.  The environment
var %ProgramFiles% holds the correct path.  There is an API call too.

--
nosy: +carlfk

_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1284316
_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com