On Fri, Mar 30, 2012 at 12:07 PM, Éric Araujo <mer...@netwok.org> wrote: > Le 29/03/2012 22:04, Nick Coghlan a écrit : >> On Fri, Mar 30, 2012 at 4:26 AM, Carl Meyer <c...@oddbird.net> wrote: >>> I've added this option as a comment on bug 14444. The title of that bug >>> is worded such that it could be reasonably resolved either with the >>> backwards-compatibility fix or the release notes addition, the release >>> managers can decide what seems appropriate to them. >> +1 for restoring the fallback code in os.py. A security release >> definitely shouldn't be breaking that kind of thing. > > The RMs have already agreed not to restore the fallback, and the > maintainer of virtualenv agreed. See report for more details.
The details are pretty short (and make sense), so I'll repeat the most salient points here for the benefit of others: - if the binary in a virtualenv isn't updated, then projects running in a virtualenv won't receive the security fix when the updated version of Python is installed - restoring the fallback in os.py would make this failure mode *silent*, so a user could upgrade Python, set PYTHONHASHSEED, but fail to realise they also need to update the binary in the virtualenv in order to benefit from the hash protection - with the current behaviour, failing to upgrade the binary results in a noisy ImportError or AttributeError related to os.urandom, which the release notes and virtualenv help channels can instruct people on handling. This approach explicitly covers the additional steps needed to fully deploy the security fix when using virtualenv. That rationale makes sense to me, too. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
