Message217031
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:54 | dstufft | set | recipients:
+ dstufft, ncoghlan, janssen, pitrou, giampaolo.rodola, christian.heimes, benjamin.peterson, alex |
2014-04-22 21:40:54 | dstufft | set | messageid: <1398202854.73.0.212097432636.issue21306@psf.upfronthosting.co.za> |
2014-04-22 21:40:54 | dstufft | link | issue21306 messages |
2014-04-22 21:40:54 | dstufft | create | |
|