EL8 w/ FIPS Enabled and Poorly-Signed RPMs

Latest response

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!


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.

Looks like I'll need to try re-signing on a non-FIPS system:

$ rpm --addsign amazon-ssm-agent.rpm
error: not signing corrupt package amazon-ssm-agent.rpm: Payload SHA256 digest: NOTFOUND


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.

unfortunately it isn't. you get the same output if you use --resign

I am wondering if re-building the package on an el8 system with fully enabled fips mode would fix the issue?


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
egrep -q "release 8" /etc/redhat-release 2>/dev/null
if [ $? -eq 0 ]
   fipschk="$(fips-mode-setup --check 2>/dev/null | egrep "is enabled")"
   fipschk="$(grep fips /proc/cmdline)"

if [ "$fipschk" != "" ]
   rpminstflag="--nodigest --nofiledigest"


Dusan Baljevic (amateur radio VK2COT)

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.

Hi Thomas,

By accident, I uncovered a method to install RPMs on a FIPS-enabled RHEL 8.4 server with YUM/DNF.

Take a look at my other post in this forum:


Best wishes,

Dusan Baljevic (amateur radio VK2COT)