From ${URL} : Common Vulnerabilities and Exposures assigned an identifier CVE-2013-1633 to the following vulnerability: Name: CVE-2013-1633 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1633 Assigned: 20130206 Reference: http://www.reddit.com/r/Python/comments/17rfh7/warning_dont_use_pip_in_an_untrusted_network_a/ Reference: https://pypi.python.org/pypi/setuptools/0.9.8#changes easy_install in setuptools before 0.7 uses HTTP to retrieve packages from the PyPI repository, and does not perform integrity checks on package contents, which allows man-in-the-middle attackers to execute arbitrary code via a crafted response to the default use of the product. @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
(In reply to Agostino Sarubbo from comment #0) > easy_install in setuptools before 0.7 uses HTTP to retrieve packages > from the PyPI repository, and does not perform integrity checks on > package contents, which allows man-in-the-middle attackers to execute > arbitrary code via a crafted response to the default use of the > product. > > > @maintainer(s): after the bump, in case we need to stabilize the package, > please say explicitly if it is ready for the stabilization or not. I think 0.8 should be the current stable candidate. It's month old, and passes tests with py2.6-3.3. But before stabilization, I'd like to backport my patch from -0.9.8-r1 to it since it fixes serious damage that easy_install is able to do to the system (bug #468378). As for <0.7, I've seen a single package depending on it and it's stevedore-0.8-r1. However, 0.9 is stable so I think we can simply drop it.
CVE-2013-1633 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-1633): easy_install in setuptools before 0.7 uses HTTP to retrieve packages from the PyPI repository, and does not perform integrity checks on package contents, which allows man-in-the-middle attackers to execute arbitrary code via a crafted response to the default use of the product.
GLSA request filed.
This issue was resolved and addressed in GLSA 201310-09 at http://security.gentoo.org/glsa/glsa-201310-09.xml by GLSA coordinator Sean Amoss (ackle).