Bug 1287610

Summary: yum message in output when FIPS is enabled
Product: Red Hat Enterprise Linux 7 Reporter: Pavel Studeník <pstudeni>
Component: yumAssignee: Michal Domonkos <mdomonko>
Status: CLOSED ERRATA QA Contact: Eva Mrakova <emrakova>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: asakpal, emrakova, james.antill, jsefler, kbost, kresss, lesley.j.kimmel, pgozart, sheridank, viviano.brad, vmukhame, vrjain, yuefliu
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: yum-3.4.3-155.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 15:05:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1420851, 1465896, 1466368    

Description Pavel Studeník 2015-12-02 12:50:08 UTC
Description of problem:
I enabled FIPS on RHEL7.2 and when I used yum this mode, I received message on output. 

>> LC_ALL=C yum repolist --disablerepo=*
Checksum type 'md5' disabled
Loaded plugins: product-id, search-disabled-repos, subscription-manager
repolist: 0

Version-Release number of selected component (if applicable):
yum-3.4.3-132.el7.noarch

How reproducible:
always

Steps to Reproduce:
1. enable FIPS
2. python -c "import yum"
Checksum type 'md5' disabled

Actual results:
on output: Checksum type 'md5' disabled

Expected results:
without this messages

Comment 4 yuefliu 2017-04-06 08:18:48 UTC
The bug still exits on RHEL-7.4-20170330.n.1 with 'yum-3.4.3-154.el7.noarch' when run "yum" and "subscription-manager".

Comment 5 Lesley Kimmel 2017-04-21 13:31:20 UTC
I don't know if this is a useful or new data point, but I just kickstarted a system using 'fips=1' from the get-go and did not encounter this issue. However, with systems built without fips mode and transitioned later it does occur.

Comment 7 Karel Srot 2017-07-18 07:02:54 UTC
IMHO the message should be printed in debug mode only.

Comment 8 Brad Viviano 2017-08-03 11:22:15 UTC
After upgrading to RHEL 7.4 with FIPS enabled I am now getting a nightly email from cron because of /etc/cron.daily/rhsmd on all of my RHEL 7.4 systems about:

Checksum type 'md5' disabled

This should be fixed in /usr/libexec/rhsmd or /etc/cron.daily/rhsmd should do something useful with the output, instead of me getting one message per system per day about this.

Comment 13 Michal Domonkos 2017-09-15 09:00:18 UTC
I made a patch that removes the "Checksum type 'md5' disabled" message when in FIPS mode so that the user is not confused/bothered in normal yum operations that don't involve md5 (most common scenario).  However, if yum actually tries to access a repo using md5 hashes while in FIPS mode, it will now at least state the reason in the error message that normally appears when a just downloaded metadata file doesn't verify:

old message: "Error performing checksum"
new message: "Error performing checksum: md5 algorithm is not FIPS compliant"

Upstream PR:
https://github.com/rpm-software-management/yum/pull/51

Comment 14 Michal Domonkos 2017-09-15 09:11:22 UTC
(In reply to Karel Srot from comment #7)
> IMHO the message should be printed in debug mode only.

This is actually not quite possible due to the fact that the message is printed during the misc.py module initialization, at which point logging hasn't been configured yet and we also haven't parsed the command line (to know we're in debug mode).  So I just removed the message for the FIPS case; logging it in debug mode wouldn't have any real benefits anyway (we do print an error if md5 is actually used, see comment 13).

Comment 15 Michal Domonkos 2017-09-15 09:16:07 UTC
(In reply to Michal Domonkos from comment #13)
> However, if yum actually tries to access a repo using md5 hashes while in FIPS mode

s/using/which uses/

Comment 22 errata-xmlrpc 2018-04-10 15:05:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0845