EL8 w/ FIPS Enabled and Poorly-Signed RPMs
It seems like, once you enable FIPS mode on RHEL 8, RPM-validation becomes fairly hardcore. If a vendor supplies an RPM that is unsigned or weakly-signed or has digests that use use weak algorithms, yum/dnf will refuse to install the package.
While one can still specify --nogpgcheck at run-time (or set gpgcheck=0 in a given RPM's repo's configuration file) to get yum/dnf to ignore the RPM's signing-key, doing so does not get rid of the digest errors.
As near as I can tell, it seems like the only workaround is to use the rpm command, instead. This is subideal for us as most of the automation we have in place for RHEL6 and RHEL7 expect to be able to use yum rather than rpm. I looked through the dnf man pages (and upstream documentation), but it doesn't seem like there's a method for disabling the digest-checking? Can someone tell me if I've missed something, and, if so, what that something might be?
Thanks in advance!
Responses
Guru
2236 points
Do you have your own GPG key that you can use to sign RPMs? If so, consider re-signing the unsigned or weakly-signed vendor RPMs (Oracle-provided RPMs were a problem for me in the not-too-distant past, so I got used to signing or re-signing their packages before uploading them to custom repos on my Satellite 6.x server). Of course, this assumes you are using a Satellite (or at least your own repo server in some form), not directly installing from vendor repos.
Guru
Community Member
4130 points
Yeah, we did that on EL7 (and it worked, even if it feels really icky to re-sign someone else's RPMs). Unfortunately, don't know that it will work for EL8. Yum (dnf) on EL8 seems more to be puking on the RPMs' file digests (or their utter lack) rather than the weak GPG keys.
That said, worth a shot to check if the weak/missing file digests problem is addressed via re-signing.
Guru
2689 points
Hi,
I agree with all comments in this thread.
As many vendors are not signing or building their packages, we are stuck with sub-optimal alternatives.
For example, as part of automation for some applications, I use this piece of Shell code:
# Check if FIPS mode enabled
#
rpminstflag=""
egrep -q "release 8" /etc/redhat-release 2>/dev/null
if [ $? -eq 0 ]
then
RPMCOMM="dnf"
fipschk="$(fips-mode-setup --check 2>/dev/null | egrep "is enabled")"
else
RPMCOMM="yum"
fipschk="$(grep fips /proc/cmdline)"
fi
if [ "$fipschk" != "" ]
then
rpminstflag="--nodigest --nofiledigest"
fi
Regards,
Dusan Baljevic (amateur radio VK2COT)
Guru
Community Member
4130 points
While the above is great, it's just proof that you're not going to be able to use Ansible's/SaltStack's/etc.'s native package-management modules to manage the installation of such software. Instead, you'd need to resort to a shell:-type kludge. And, the problem of resorting to those is that they tend to provide less direct paths to automation-idempotency. Factor in too many years of support tickets being opened by RHEL-using customers around "why do I keep getting 'RPMDB altered outside of yum' errors" (that's still a problem on RHEL8?) makes me gun-shy of methods that might trigger such.