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 dstufft
Recipients alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou
Date 2014-04-22.21:40:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1398202854.73.0.212097432636.issue21306@psf.upfronthosting.co.za>
In-reply-to
Content
I'm not sure that the timing leakage in an encode is actually something to be worried about. I'm not sure what secret information would be getting leaked in a way that you could determine it by examining the timing.

However I think the bigger thing is if I'm an app developer and I attempt to pass a unicode to hmac.compare_digest() and it tells me it only accepts bytes, the first thing I'm going to do is is .encode() it myself before I pass it in.

IOW hmac.compare_digest could avoid the encode, but it's just pushing that back up to the user of hmac.compare_digest, who might possibly have a byte string laying around that they won't have to do the encode/decode dance on (although if they have a unicode they have already done it at least once), or they only have a unicode available to them then they'll be forced to do the encode themselves.
History
Date User Action Args
2014-04-22 21:40:54dstufftsetrecipients: + dstufft, ncoghlan, janssen, pitrou, giampaolo.rodola, christian.heimes, benjamin.peterson, alex
2014-04-22 21:40:54dstufftsetmessageid: <1398202854.73.0.212097432636.issue21306@psf.upfronthosting.co.za>
2014-04-22 21:40:54dstufftlinkissue21306 messages
2014-04-22 21:40:54dstufftcreate