Packages signed with SHA-1 cannot be installed or upgraded

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9

Issue

  • The Leapp upgrade utility is reporting a warning during pre-assessment run that RPM packages with RSA/SHA1 signatures were detected and as a result a system upgrade is not possible.
  • Installing RPM packages with SHA-1 signature on a RHEL 9 system is failing with an error.

Resolution

To find out if you have any packages installed on your system that use SHA1 signatures, you can run the following command:

# rpm -qai | egrep '^(Name|Signature) *:' | egrep -B 1 'SHA1'

It is recommended to contact vendors of such packages to ask them for new builds signed with supported signatures and install the new packages. Another option is to resign packages with your own SHA-2 key or completely remove packages until a new build with SHA-2 signature is available from the 3rd party vendor.

It’s technically possible to force installing unsupported packages on RHEL-9, by applying a SHA1 cryptographic sub-policy:

# update-crypto-policies --set DEFAULT:SHA1

Please note though that this option is not recommended as it weakens system security. The recommended option is to requst RHEL-9 compatible packages instead.

In case of upgrading from RHEL-8 to RHEL-9, switching to LEGACY for the duration of the upgrade will also allow RPM operations with packages signed with SHA-1:

# update-crypto-policies --set LEGACY

Once the upgrade to RHEL-9 is complete, the DEFAULT crypto-policy can be used together with the SHA-1 sub-policy:

# update-crypto-policies --set DEFAULT:SHA1

The use of neither LEGACY policy nor SHA1 sub-policy is recommended by Red Hat for networked systems as they do not provide secure defaults. The possibility to do that is documented only for completeness. The recommended option is to request RHEL-9 compatible packages instead.

Alternatively, you can disable signature checking just for a single DNF transaction by using the --setopt=tsflags=nocrypto option, for example:

# dnf install --setopt=tsflags=nocrypto /path/to/the/package.rpm

Alternatively, you can use the rpm(8) utility directly with the --nosignature option:

# rpm -Uhv --nosignature /path/to/the/package.rpm

Note that to query or remove such a package later, you must use the same command-line switches as above. Otherwise, RPM or DNF show the following error:

error: rpmdbNextIterator: skipping h# error-message-number

This error can be confusing if it occurs during a larger removal transaction where you do not know the problematic package beforehand. To identify such a package, use the following command:

# rpm -q --nosignature --querybynumber error-message-number

Replace error-message-number by the number printed in the previously mentioned error message.

Root Cause

The SHA-1 message digest has been deprecated in Red Hat Enterprise Linux 9. The digest produced by SHA-1 is not considered secure because of many documented successful attacks based on finding hash collisions. The RHEL core crypto components no longer create signatures using SHA-1 by default. Applications in RHEL 9 have been updated to avoid using SHA-1 in security-relevant use cases. This causes issues when using DNF/RPM to handle packages with RSA/SHA1 signatures as the signature cannot be checked with the default cryptographic policy. Any such packages cannot be installed, removed, or replaced unless the signature check is disabled in DNF/RPM or SHA-1 is enabled using non-default crypto-policies.

Please note that, in the unlikely case that packages signed with a SHA1 key have been built on modern RHEL, they may have SHA256 digests and, if they do, they'll install successfully with the RHEL 9 DEFAULT crypto-policy in place:

[root@rhel9 ~]# rpm -Kv foo-1-0.noarch.rpm
foo-1-0.noarch.rpm:
    Header V4 DSA/SHA1 Signature, key ID 71567BD2: NOKEY
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    V4 DSA/SHA1 Signature, key ID 71567BD2: NOKEY
    MD5 digest: OK

Customers are still encouraged to generate a newer key using stronger algorithms and use it to sign packages. RHEL 10 will reject packages signed with SHA1 keys even if they have SHA256 digests.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.