Description of problem:

On FIPS enabled systems, after upgrading past rhncfg-5.10.55-8, rhncfg-client stops working

Version-Release number of selected component (if applicable):

DSSH:[root@hpc9-io-01d ~]# rpm -qa|grep rhncf
rhncfg-client-5.10.74-7.el6sat.noarch
rhncfg-5.10.74-7.el6sat.noarch
rhncfg-management-5.10.74-7.el6sat.noarch
rhncfg-actions-5.10.74-7.el6sat.noarch

How reproducible:


Steps to Reproduce:
1.rhncfg-client verify on any update of rhncfg after rhncfg-5.10.55-8


Actual results:

After upgrade of package:
[root@hpc9-io-01d ~]# rhncfg-client verify
Using server name labsat.it.census.gov
Traceback (most recent call last):
  File "/usr/bin/rhncfg-client", line 38, in <module>
    sys.exit(Main().main() or 0)
  File "/usr/share/rhn/config_common/rhn_main.py", line 207, in main
    handler.run()
  File "/usr/share/rhn/config_client/rhncfgcli_verify.py", line 73, in run
    (src, file_info, dirs_created) = self.repository.get_file_info(file)
  File "/usr/share/rhn/config_client/rpc_cli_repository.py", line 91, in get_file_info
    temp_file, dirs_created = f.process(result, directory=dest_directory)
  File "/usr/share/rhn/config_common/file_utils.py", line 80, in process
    file_struct['checksum_type'], contents):
  File "/usr/share/rhn/config_common/utils.py", line 159, in getContentChecksum
    engine = hashlib.new(checksum_type)
  File "/usr/lib64/python2.6/hashlib.py", line 83, in __hash_new
    return _hashlib.new(name, string, usedforsecurity)
ValueError: error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips


Expected results:

Upgrading to SAT 5.7 would resolve the issue but AFWA (662708) is running SAT 5.6 on RHEL 5 in a classified environement. Upgrading to 5.7 is not possible in the near future. 


Additional info:

Comments from customer:

Mike,

I find that answer really frustrating.  In our environment, we have an operational satellite server in a classified environment that is running on top of RHEL5.  As a result, we can't simply upgrade it to Satellite 5.7 (since that requires RHEL6).  Making changes in that environment takes a lot of time and coordination - it won't be a fast process.  

I understand (and support) the migration to a FIPS-compliant environment.  However, I find this frustrating because I wouldn't expect Red Hat to break backwards compatibility within dot-releases of the OS.   On top of that, the suggested workaround of setting "usedforsecurity=False" within the hashlibs module is very hard to actual implement.  Using this technique would require us to modify a Red Hat-provided file.  This implies we then need to manage the file within our satellite server and manually re-push the file every time the python-libs RPM gets updated.  This would mean we would deploy a new RPM at version xyz, and then overwrite a single file with our baselined version from 3 versions back (or something like that).  That would potentially break all sorts of things!  Making a behavior-changing variable like this should be configurable within a config file, environment variable, or similar mechanism - not by hard-coding it inside of actual code.

In my opinion, it would not have been terribly hard for Red Hat to maintain backwards compatibility for the rhntools (rhncfg) packages. The rhncfg script should be able to tell what version of Satellite server it is talking to, and automatically set the usedforsecurity=False flag for any satellite server that is not capable of supporting FIPS (5.6 or below).  That seems like a simple if/then statement that would allow your RHEL6 clients to continue working as they did before, and allow customers like us that are transitioning into a fully-FIPS environment to do so without breaking functionality. 

All of my Red Hat products invovled here (RHEL5, RHEL6, Satellite 5.6) are fully supported and were working together properly, yet we experienced a big loss of functionality after upgrading.  This should not be, and I feel could have been avoided.