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 serhiy.storchaka
Recipients Jon.Oberheide, alex, christian.heimes, fijall, georg.brandl, hynek, loewis, ncoghlan, petri.lehtinen, pitrou, python-dev, serhiy.storchaka
Date 2012-06-22.06:08:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340345342.2703.43.camel@raxxla>
In-reply-to <1340314923.3400.0.camel@localhost.localdomain>
Content
> > > We could handle all bytes-compatible objects, using the buffer API.
> > It is timing unsafe.
> How so?

I checked myself, and I see that most likely I was wrong. At least for
bytes and bytearrays it is timing safe.

> I don't think that's the right answer, because people will instead e.g.
> encode('utf-8'), and suddently the encodingly will not be timing-safe.

And what of that? It is outside of the timingsafe_eq function. People
can also do other timing unsafe operations with the secret key (for
example reading it from file or from DB) or not to use timingsafe_eq at
all. The secret key should be pre-encoded.

The error will be if code works for developer from ASCII word, and then
on the other side of ocean it will no longer work with non-ASCII
strings. You are expected to be familiar with such issues. In any case,
the obvious (and simplest, and fastest) way to check that a string is
ASCII-only is try to encoded it to ASCII.
History
Date User Action Args
2012-06-22 06:08:53serhiy.storchakasetrecipients: + serhiy.storchaka, loewis, georg.brandl, ncoghlan, pitrou, christian.heimes, alex, fijall, python-dev, petri.lehtinen, hynek, Jon.Oberheide
2012-06-22 06:08:52serhiy.storchakalinkissue15061 messages
2012-06-22 06:08:51serhiy.storchakacreate