_hmac module bypasses --with-builtin-hashlib-hashes by embedding all HACL hash implementations

[stratakis]

Bug report

Bug description:

When configuring Python with e.g. --with-builtin-hashlib-hashes=blake2 to build only the blake2 builtin hash module, the _hmac module is still unconditionally built and embeds all HACL hash implementations (MD5, SHA1, SHA2, SHA3, Blake2).

While in these cases the excluded hashes are not built as extension modules, since they are compiled into _hmac, then md5 and other disabled digests can still be computed

>>> import _hmac
>>> _hmac.compute_digest(b'key', b'msg', 'md5')
b'\x18\xe3T\x8cY\xad@\xdd\x03\x90{z\xee\xe7\x1dg'

Not sure if that is intended behaviour or an oversight but it seems to defeat the purpose of excluding specific hashes. Also increases the size of _hmac substantially. Discovered it when working on a FIPS build.

On our FIPS build I opted for completely disabling _hmac in this case (FIPS builds only utilize OpenSSL anyway for hmac)

CPython versions tested on:

3.15, 3.14

Operating systems tested on:

Linux

[stratakis]

cc @picnixz

[picnixz]

Yes this is expected. HMAC is also HACL* based so it requires the same sources and the upstream does not allow me to selectively disable some of them unfortunately.

[picnixz]

@protz Is there a plan to be able to selectively disable some algorithms in HMAC through some ifdefs maybe?

[protz]

Good question. The design did not originally plan for it -- I guess the multiplexing would have to guard algorithm selection behind an ifdef. It should feasible, but not trivial.

Is this critical?

I'm offline for the next three weeks but happy to resume discussion once I'm back. Cheers!

[stratakis]

I wouldn't call it critical but definitely unexpected behaviour for CPython when a user or distributor compiles the interpreter and decides to exclude specific digests.