-
-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
_sha256 et al. encode to UTF-8 by default #47995
Comments
Whereas openssl-based _hashlib refuses to accept unencoded strings: >>> _hashlib.openssl_sha256("\xff")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object supporting the buffer API required the _sha256 version encodes to UTF-8 by default: >>> _sha256.sha256("\xff").digest() ==
_sha256.sha256("\xff".encode("utf-8")).digest()
True I think refusing is better, but at least the behaviour should be |
agreed. most platforms should be using the openssl version, i will I don't think this is worth being a release blocker. I'll do it for 3.0.1. |
Seems that this problem is being taken care of in issue bpo-4751. |
Fixed in py3k branch r69524. needs porting to release30-maint. possibly also release26-maint and trunk. |
I don't think backporting to 2.6 is fine, people may be relying on the |
Wooops, my mouse clicked on Remove!? I removed Message73550, sorry I don't think this is worth being a release blocker. I'll do it for |
I agree with pitrou: leave python 2.6 unchanged, but please backport |
gpolo gave me the solution to restore a deleted message: |
fixed in release30-maint r69555. sounds like its out of the question for 2.6. i will backport it to |
fixed in trunk r69561. |
Gregory, this patch should not have been backported to Python 2.7. See issue Could you please revert the change on trunk ? Thanks. A much better solution would be to issue a -3 warning in case a Unicode |
What about inconsistent module build - as is reported some platform |
lemburg - see which issue #? Anyways perhaps the right thing to do instead of trunk r65961 would have Undoing it will be more painful now as several changes have gone in since |
rpetrov - I couldn't really understand your message so I'm not sure if I'm |
I think the missing issue reference is to this thread on python-dev: http://mail.python.org/pipermail/python-dev/2009-December/094574.html |
gregory - refer to setup.py logic to build modules |
Gregory P. Smith wrote:
Sorry, the message got truncated for some reason. I was referring to http://bugs.python.org/issue3745 This was discussed on python-dev: http://mail.python.org/pipermail/python-dev/2009-December/094593.html
That would have worked as well.
Using s* should pretty much avoid the need to use GET_BUFFER_VIEW_OR_ERROUT(), |
trunk r77252 switches python 2.7 to use 's*' for argument parsing. unicodes can be hashed (encoded to the system default encoding by s*) again. This change has been blocked from being merged into py3k unless someone decides we actually want this magic unicode encoding behavior to exist there as well. setup.py has also been updated to compile all versions of the hash algorithm modules when Py_DEBUG is defined. I'll update tests run on all implementations next so that it is easier for developers to maintain identical behavior across all implementations without needing to explicitly remember to reconfigure their setup and test those. |
In order to get a -3 PyErr_WarnPy3k warning for unicode being passed to hashlib objects (a nice idea) I suggest creating an additonal 's*' like thing ('s3' perhaps?) in Python/getargs.c for that purpose rather than modifying all of the hashlib modules to accept an O, type check it and warn, and then re-parse it as a s* (that'd be a lot of tedious code duplication). |
I believe everything in here has been addressed. Please open new issues with details for anything that doesn't quite right. |
Gregory P. Smith wrote:
Thanks for updating the implementation. |
Gregory P. Smith wrote:
Good idea. We're likely going to need this in more places, so I'm +1 on |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: