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 <>
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.
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: <>
2014-04-22 21:40:54dstufftlinkissue21306 messages
2014-04-22 21:40:54dstufftcreate