hashlib: import pure python hash first to unbreak the hmac module #435
Conversation
With the current import strategy that favours the uhashlib
implementation before using the "internal" hashlib version external
modules like "hmac" break because the uhashlib versions lack properties
like `{digest,block}_size, copy()`.
This commit changes the import so that the internal version of the
hash is tried to be imported first and only if there is no internal
version then the uhashlib version is used.
|
I love micropython and would love to see this issue fixed. Is there anything I can do/should do to move this forward? I'm happy to write test cases or anything else that might help :) |
|
@jimmo Can you provide some feedback on this PR ? |
|
Thanks @mvo5 and sorry this has taken so long. It's preferable to use the built-in one where possible -- e.g. an app that only needs to do sha256 hmacs shouldn't need to install hashlib from micropython-lib if the device already has it. I agree it would be good to update uhashlib's ones to support hmac (as per micropython/micropython#4539) but hmac strictly doesn't need these extensions to function. So instead I think it's better to solve this by making the |
|
Thanks @jimmo - using the buildin hashes by default of course makes a ton of sense - thank so much for fixing hmac with the buildin hashes too, really appreicated! |
With the current import strategy that favours the uhashlib
implementation before using the "internal" hashlib version external
modules like "hmac" break because the uhashlib versions lack properties
like
{digest,block}_size, copy().This commit changes the import so that the internal version of the
hash is tried to be imported first and only if there is no internal
version then the uhashlib version is used.
This should fix #384
I guess as an alternative we could try to make uhashlib compatible with hmac.
This should be relatively straightforward and was done in micropython/micropython#4539 but wasn't received favorable there.