Bug 969395

Since the update is fixing two security problems... it might be better to leave the broken update and retire the package.  (I've just noticed a third security issue while evaluating this).

Talking to the pip maintainer, he's debating retiring pip in EL5 as well which would very much incline me to the notion that retiring python-virtualenv is the right thing to do.  (virtualenv bundles pip and the bundled pip is where the currently known vulnerabilities lie).

It would be possible for someone to create python26-pip and python26-virtualenv packages after pip is retired which would fill the gap for some end users.

Of course I know EPEL is run by volunteers but retiring the package seems to be a really unfriendly move to me. Personally I'd rather have the security issue (local only!) than no virtualenv module. 

A better way for would be to remove pip (but virtualenv!) would be ok as users can still use easy_install (and some common virtualenv-related use cases do not use neither pip nor easy_install).

That sounds reasonable.  I'm away for two days but I'll see what I can do on Wed.

I looked into this briefly on Friday (in case someone else wants to take a crack at it or I get busy with other things on Wed).  I think that we can just remove the pip tarball and virtualenv will continue to work (and will fallback to using its bundled easy_install :-/ )

There's some issues with this, though --

1) easy_install suffers from one of the security issues that the earlier pip does (not using https to download packages and thus being succeptible to MITM attacks).

2) virtualenv will attempt to download pip from pypi which will either download a pip that doesn't work on python-2.4 or will download the older, insecure version of pip that does work.

Until 1) is remedied in upstream setuptools, that might just be something to think of as a known missing security feature.

2) is something we need to look into and document.  Perhaps a warning printed to stderr (or to the logger) about pip being incompatible with py2.4 or insecure depending on what virtualenv is doing here.

personally I'd say that all this 'download packages over http' is over the top from what easy_install/pip wanted to do in the first place. So it is nice that additional security is added but in the end to me it's a new feature and not a security issue. It works as designed and all security implications were known at release time.

Also just plain HTTPs doesn't really help as long as pip does not check for a "valid" certificate (signed by a well-known CA).

Insecure temporary files are a local security issue but only a minor one for many users. So I'm glad that you didn't insist on pulling a working package from EPEL. Also one might argue that only "critical" issues are fixed at that stage in EPEL.

* The patch to pip appears to turn on cert checking: https://github.com/pypa/pip/pull/791  -- at least, it both adds a CA bundle and the ssl.check_hostname function that would be necessary to do so.

* Making progress on this.  virtualenv always attempts to download the latest version of pip so virtualenv is broken in this case.  I can patch virtualenv to add a logger message that explains the security issue and how to manually download and make use of the older version of pip if the user evaluates the problems as not applying to them.

Okay, here's the new behaviour.  I'll build a package with the changes that implement this:

$ virtualenv test
New python executable in test/bin/python
Installing setuptools.............done.
Can't find any local distributions of pip to install and virtualenv can't download a secure version of pip that works with your python version (2.4.x).  If you evaluate the unfixed security issues in pip-1.1 ( as of this writing: https://github.com/pypa/pip/issues/425 and https://github.com/pypa/pip/issues/725 ) and decide they do not apply to your environment you may manually download the pip-1.1 source distribution from pypi ( https://pypi.python.org/packages/source/p/pip/pip-1.1.tar.gz ) and place it in one of these locations: ['.', '/usr/lib/python2.4/site-packages', '/usr/lib/python2.4/site-packages/virtualenv_support', '/usr/lib/python2.4/site-packages/virtualenv_support']

$ wget https://pypi.python.org/packages/source/p/pip/pip-1.1.tar.gz --no-check-certificate 
--2013-06-06 14:27:18--  https://pypi.python.org/packages/source/p/pip/pip-1.1.tar.gz
Resolving pypi.python.org... 199.27.77.192, 199.27.77.129
Connecting to pypi.python.org|199.27.77.192|:443... connected.
WARNING: certificate common name `*.a.ssl.fastly.net' doesn't match requested host name `pypi.python.org'.
HTTP request sent, awaiting response... 200 OK
Length: 95197 (93K) [application/octet-stream]
Saving to: `pip-1.1.tar.gz'

100%[============================================================================================>] 95,197       595K/s   in 0.2s    

2013-06-06 14:27:18 (595 KB/s) - `pip-1.1.tar.gz' saved [95197/95197]

$ rm -rf test
$ virtualenv test
New python executable in test/bin/python
Installing setuptools.............done.
Installing pip...............done.
$

python-virtualenv-1.7.2-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/python-virtualenv-1.7.2-2.el5

Package python-virtualenv-1.7.2-2.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing python-virtualenv-1.7.2-2.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-10396/python-virtualenv-1.7.2-2.el5
then log in and leave karma (feedback).

python-virtualenv-1.7.2-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.