Ensure that hashlib.<name> does not raise AttributeError #136929
Description
Feature or enhancement
Proposal:
Let's summarize the current behavior of hashlib. We have two interfaces for getting digests: hashlib.new(digest, ...) and hashlib.<digest>().
With hashlib.new() it depends on the presence of OpenSSL. If OpenSSL is present, and if it's not a BLAKE-2 (this is a special case that I'll talk about it later), we check if OpenSSL recognizes the digest and the security policy allows it. If this is not the case, we fall back to the built-in implementation, and we don't care about the security policy here. If the built-in doesn't exist, then we raise an exact ValueError.
With hashlib.md5() (and anything else except "blake2"), this is much more subtle. Named constructors are determined at import time and solely depend on the presence of OpenSSL. More precisely, if OpenSSL and the security policy allows it, then hashlib.md5 is set to _hashlib.openssl_md5. And this doesn't change for the interpreter's lifetime.
On the other hand, if the security policy doesn't allow it, then we still set hashlib.md5 to _hashlib.openssl_md5. This means that we will not be able to use it unless we explicitly pass usedforsecurity=False here. Now, without OpenSSL, we set the named constructors to the corresponding built-in HACL functions.
Now, as I said, the problem is about import hashlib when neither OpenSSL nor HACL* are present. Instead of raising an AttributeError when trying to access the function, we should either raise an ImportError, or create mock functions for hash functions that raise ValueError at runtime (which would be ideal IMO). That way, we can ensure that tests using cryptographic hashes are decorated with "@requires_hashdigest" and make build bots that are match by "FIPS" successful.
The case for blake2 is a bit different because we actually do not care about OpenSSL at all! IOW, hashlib.blake2 is solely HACL* implemented except that we can still access it via hashlib.new("blake2b512", ...).
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response