Fix library in FIPS mode #83
Conversation
disabling and enabling warnings is sometimes necessary (e.g. when matching behaviour of 3rd party code), verifying if local enabling or disabling of warnings is not abused is reviewers job, as pylint can't check if the disablement has a sensible comment before it
tomato42
force-pushed
the
fips-fixes
branch
2 times, most recently
from
a0b7438
to
1ea560b
Compare
by using * import we are importing a lot of extraneous garbage, use specific imports only
In FIPS mode use of MD5 is restricted while use of RC4 is disallowed, so we need to make the library indicate to hashlib that we will use MD5 "carefully" and in case of RC4, we simply don't use m2crypto in FIPS mode
|
The QuantifiedCode failure is caused by the need to extend |
|
@The-Mule: r? |
|
Overall it looks good, I've just one minor remark, AFAIK hashlib uses openssl which can itself run in "FIPS mode" regardless of the rest of the system (as long as OPENSSL_FORCE_FIPS_MODE env. var. is non-empty). I am a little disappointed that hashlib does not have API for FIPS mode detection. Using just kernel fips flag might not be 100% reliable, it would be good to check /etc/system_fips albeit that is used just in RHEL and Fedora... The most reliable (and the ugliest) way would be just checking if md5 works in hashlib, if so, FIPS mode is disabled, otherwise enabled. Anyway, I am okay with the current solution for the time being (FIPS mode does not respecting kernel fips flag is really corner case). r+ |
|
the FIPS detection is unrelated to hashlib, the while for RC4 M2Crypto uses essentially the same code: https://gitlab.com/m2crypto/m2crypto/blob/master/tests/fips.py |
there are some additional limitations on behaviour of
m2cryptoandhashlibwhen system is working in FIPS mode - workaround those