This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients arigo, christian.heimes, fijall, hynek, loewis, ncoghlan, pitrou
Date 2012-06-15.07:45:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <4FDAE828.4090406@v.loewis.de>
In-reply-to <1339745322.17.0.324661024268.issue15061@psf.upfronthosting.co.za>
Content
> The timing variations with standard comparison are relatively massive
> and relatively easy to analyse (if the time taken goes up, you got
> the previous digit correct).

If you have an application that is vulnerable to such an attack, you
better reconsider your entire approach, rather than using a library
function that says it will harden your approach (but may
actually not).

> Yes, the docs and name are currently completely unacceptable. But
> scorched earth is not a good answer, because that just means people
> will fall back to using "==" which is *even worse* from a security
> point of view.

It's not scorched earth. It's the standard procedure for adding features
to the standard library. *At a minimum* there needs to be a use case,
which has not been demonstrated yet (the OP of the original report
thought he had a use case, but then agreed that he was wrong). Then,
the use case should be fairly relevant for inclusion in the standard
library. I wish there was an AES implementation in the library before
we start worrying about stuff like this. Then, ideally, the new library
function has been in wide use for some time.

This was rushed, and it needs to be reverted.
History
Date User Action Args
2012-06-15 07:45:47loewissetrecipients: + loewis, arigo, ncoghlan, pitrou, christian.heimes, fijall, hynek
2012-06-15 07:45:46loewislinkissue15061 messages
2012-06-15 07:45:46loewiscreate