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