Bug 969395 - virtualenv does not work anymore because Python 2.4 support was dropped in virtualenv 1.9
virtualenv does not work anymore because Python 2.4 support was dropped in vi...
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: python-virtualenv (Show other bugs)
el5
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Steve Milner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-31 07:08 EDT by Felix Schwarz
Modified: 2013-06-24 17:05 EDT (History)
5 users (show)

See Also:
Fixed In Version: python-virtualenv-1.7.2-2.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-24 17:05:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Felix Schwarz 2013-05-31 07:08:08 EDT
recently python-virtualenv in EPEL5 was upgraded to 1.9 to fix bug 923974. 

However this completely breaks virtualenv on EPEL5 because virtualenv 1.9 requires Python 2.5+ and RHEL5 ships Python 2.4. You can verify the problem by just running the virtualenv command which will print "ERROR: this script requires Python 2.5 or greater.".

I suggest you remove the update as a stop gap measure and backport to patch to virtualenv 1.7.2 which is the last version supporting Python 2.4.
Comment 1 Toshio Ernie Kuratomi 2013-05-31 10:59:42 EDT
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.
Comment 2 Felix Schwarz 2013-05-31 13:39:26 EDT
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).
Comment 3 Toshio Ernie Kuratomi 2013-06-03 13:00:14 EDT
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.
Comment 4 Felix Schwarz 2013-06-04 03:19:12 EDT
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.
Comment 5 Toshio Ernie Kuratomi 2013-06-06 11:55:14 EDT
* 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.
Comment 6 Toshio Ernie Kuratomi 2013-06-06 16:32:17 EDT
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.
$
Comment 7 Fedora Update System 2013-06-06 17:02:39 EDT
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
Comment 8 Fedora Update System 2013-06-08 14:40:15 EDT
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).
Comment 9 Fedora Update System 2013-06-24 17:05:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.