Message162892
| Author |
pitrou |
| Recipients |
christian.heimes, fijall, hynek, loewis, ncoghlan, petri.lehtinen, pitrou, python-dev |
| Date |
2012年06月15日.12:21:38 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1339762713.3399.5.camel@localhost.localdomain> |
| In-reply-to |
<1339762571.55.0.30282178743.issue15061@psf.upfronthosting.co.za> |
| Content |
> 2. Providing a C implementation via the operator module (given the
> restriction to bytes values, and the assumption of caching for all
> relevant integers, would a C reimplementation really be buying us much
> additional security?)
I like the fact that a C implementation can be audited much more easily.
Who knows what kind of effects the Python implementation can trigger, if
some optimizations get added in the future.
> As far as restoring unicode support (even in a C implementation) goes,
> I actually don't like the idea. For the general unicode case, as
> suggested in the updated documentation for hexdigest(), I believe the
> better approach is to try to stay in the bytes domain as much as
> possible, and avoid having a Unicode->bytes conversion for the
> expected value anywhere in the comparison timing path.
The point of supporting unicode would precisely be to avoid a
unicode->bytes conversion when unicode strings are received. |
|