We're pleased to announce the immediate availability of release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . The main impetus for these releases is fixing a security issue in Python's hash based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues, 2.6.8 and 3.1.5 contain only various security patches. The security issue exploits Python's dict and set implementations. Carefully crafted input can lead to extremely long computation times and denials of service. [1] Python dict and set types use hash tables to provide amortized constant time operations. Hash tables require a well-distributed hash function to spread data evenly across the hash table. The security issue is that an attacker could compute thousands of keys with colliding hashes; this causes quadratic algorithmic complexity when the hash table is constructed. To alleviate the problem, the new releases add randomization to the hashing of Python's string types (bytes/str in Python 3 and str/unicode in Python 2), datetime.date, and datetime.datetime. This prevents an attacker from computing colliding keys of these types without access to the Python process. Hash randomization causes the iteration order of dicts and sets to be unpredictable and differ across Python runs. Python has never guaranteed iteration order of keys in a dict or set, and applications are advised to never rely on it. Historically, dict iteration order has not changed very often across releases and has always remained consistent between successive executions of Python. Thus, some existing applications may be relying on dict or set ordering. Because of this and the fact that many Python applications which don't accept untrusted input are not vulnerable to this attack, in all stable Python releases mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT. There are two ways to enable it. The -R commandline option can be passed to the python executable. It can also be enabled by setting an environmental variable PYTHONHASHSEED to "random". (Other values are accepted, too; pass -h to python for complete description.) More details about the issue and the patch can be found in the oCERT advisory [1] and the Python bug tracker [2]. These releases are releases candidates and thus not recommended for production use. Please test your applications and libraries with them, and report any bugs you encounter. We are especially interested in any buggy behavior observed using hash randomization. Excepting major calamity, final versions should appear after several weeks. Downloads are at http://python.org/download/releases/2.6.8/ http://python.org/download/releases/2.7.3/ http://python.org/download/releases/3.1.5/ http://python.org/download/releases/3.2.3/ Please test these candidates and report bugs to http://bugs.python.org/ With regards, The Python release team Barry Warsaw (2.6), Georg Brandl (3.2), Benjamin Peterson (2.7 and 3.1) [1] http://www.ocert.org/advisories/ocert-2011-003.html [2] http://bugs.python.org/issue13703
Benjamin Peterson <benjamin@python.org> writes: > We're pleased to announce the immediate availability of release candidates for > Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . If you're pleased to announce their immediate availability, then please do that! Putting “RELEASED” in the subject, when they're not released and are instead *candidates for* release, is confusing and muddies the issue of what you even mean by “release”. -- \ “Give a man a fish, and you'll feed him for a day; give him a | `\ religion, and he'll starve to death while praying for a fish.” | _o__) —Anonymous | Ben Finney
On Sun, Feb 26, 2012 at 7:51 PM, Ben Finney <ben+python@benfinney.id.au> wrote: > Benjamin Peterson <benjamin@python.org> writes: > >> We're pleased to announce the immediate availability of release candidates for >> Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . > > If you're pleased to announce their immediate availability, then please > do that! Isn't it perfectly accurate to say that the RCs are now available? Considering that "Release candidates" immediately followed "RELEASED" in the subject line, I don't see any confusion. ChrisA
Chris Angelico <rosuav@gmail.com> writes: > On Sun, Feb 26, 2012 at 7:51 PM, Ben Finney <ben+python@benfinney.id.au> wrote: > > If you're pleased to announce their immediate availability, then > > please do that! > > Isn't it perfectly accurate to say that the RCs are now available? Yes. What's not reasonable is to say that a candidate for release – i.e. something *prior to* release, by definition – is nevertheless released. > Considering that "Release candidates" immediately followed "RELEASED" > in the subject line, I don't see any confusion. Unless “release candidate” means nothing like what those words imply, it can't be both a release candidate *and* released. Either it's released, or it's not. If it's a release candidate, it's not released yet. If it's released, it's no longer a candidate for release. Saying it's simultaneously both is the confusion. -- \ “The Things to do are: the things that need doing, that you see | `\ need to be done, and that no one else seems to see need to be | _o__) done.” —Richard Buckminster Fuller, 1970-02-16 | Ben Finney
On Sun, Feb 26, 2012 at 11:21 PM, Ben Finney <ben+python@benfinney.id.au> w= rote: > Unless =93release candidate=94 means nothing like what those words imply,= it > can't be both a release candidate *and* released. > > Either it's released, or it's not. If it's a release candidate, it's not > released yet. If it's released, it's no longer a candidate for release. Sure, fair enough. So what DO you do with an RC? "Make it available"? Seems a little verbose, but it's the best I can think of off-hand. ChrisA
On Sun, 26 Feb 2012 23:21:07 +1100, Ben Finney wrote: > Chris Angelico <rosuav@gmail.com> writes: > >> On Sun, Feb 26, 2012 at 7:51 PM, Ben Finney >> <ben+python@benfinney.id.au> wrote: > >> > If you're pleased to announce their immediate availability, then >> > please do that! >> >> Isn't it perfectly accurate to say that the RCs are now available? > > Yes. What's not reasonable is to say that a candidate for release – i.e. > something *prior to* release, by definition – is nevertheless released. We have a piece of software which has just been actively released to the public in a known fixed state, with a specific version number (2.6.8rc etc.). Since this active process of *releasing* software has occurred, the past tense "[RELEASED]" applies. What sort of software is it? Well, it's not a pre-alpha, or alpha, or beta version, nor is it the production-release version. It is a candidate to become the production-release, or "Release candidate". Hence we have the release [verb] of a release candidate [compound noun]. There is no contradiction here, any more than it would be a contradiction to release a beta version. http://en.wikipedia.org/wiki/Software_release_life_cycle >> Considering that "Release candidates" immediately followed "RELEASED" >> in the subject line, I don't see any confusion. > > Unless “release candidate” means nothing like what those words imply, it > can't be both a release candidate *and* released. What do you believe the words imply? I believe that they imply that the version is a candidate to be a production-ready release of the software, as opposed to a pre-alpha, alpha or beta version, but not yet the production-ready version. -- Steven
On 2/26/2012 3:51 AM, Ben Finney wrote: > Benjamin Peterson<benjamin@python.org> writes: > >> We're pleased to announce the immediate availability of release candid= ates for >> Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . > > If you're pleased to announce their immediate availability, then please= > do that! > > Putting =E2=80=9CRELEASED=E2=80=9D in the subject, when they're not rel= eased and are > instead *candidates for* release, is confusing and muddies the issue of= > what you even mean by =E2=80=9Crelease=E2=80=9D. I think the standard [RELEASED] tag is for the benefit of people who do=20 not read the list but filter it for posts with such tags, perhaps=20 automatically, so they know there is something new to go download. And=20 indeed, there is something new to download. --=20 Terry Jan Reedy
Ben Finney <ben+python <at> benfinney.id.au> writes: > > Putting “RELEASED” in the subject, when they're not released and are > instead *candidates for* release, is confusing and muddies the issue of > what you even mean by “release”. > {alpha, beta, release candidate, final} \subsetof releases
Ben Finney wrote: > Chris Angelico <rosuav@gmail.com> writes: > > >> On Sun, Feb 26, 2012 at 7:51 PM, Ben Finney <ben+python@benfinney.id.au> wrote: >> > > >>> If you're pleased to announce their immediate availability, then >>> please do that! >>> >> Isn't it perfectly accurate to say that the RCs are now available? >> > > Yes. What's not reasonable is to say that a candidate for release – i.e. > something *prior to* release, by definition – is nevertheless released. > > >> Considering that "Release candidates" immediately followed "RELEASED" >> in the subject line, I don't see any confusion. >> > > Unless “release candidate” means nothing like what those words imply, it > can't be both a release candidate *and* released. > > Either it's released, or it's not. If it's a release candidate, it's not > released yet. If it's released, it's no longer a candidate for release. > > Saying it's simultaneously both is the confusion. > > What sort of release can you release ? A release candidate. If you can release a release candidate, a release candidate can be released, hence the released candidate release. More important, we all thank the release team for their efforts and hope they're having fun reading us :o) JM
Benjamin Peterson <benjamin@python.org> writes: > Ben Finney <ben+python <at> benfinney.id.au> writes: > > > > Putting “RELEASED” in the subject, when they're not released and are > > instead *candidates for* release, is confusing and muddies the issue of > > what you even mean by “release”. > > > > {alpha, beta, release candidate, final} \subsetof releases So you've chosen to muddy what is meant by “release” in announcements to the public. That's disappointing, but thank you for acknowledging it. I appreciate the work that goes toward releases of Python, but I do wish you'd use clear terminology in announcements. -- \ “If history and science have taught us anything, it is that | `\ passion and desire are not the same as truth.” —E. O. Wilson, | _o__) _Consilience_, 1998 | Ben Finney