Cloudstack v4.20 RPM installation fails on AlmaLinux9 when GPG verification is enabled due to SHA-1 deprecation

[computergeek125]

ISSUE TYPE

• Bug Report

COMPONENT NAME

Packaging

CLOUDSTACK VERSION

4.20

CONFIGURATION

N/A

OS / ENVIRONMENT

AlmaLinux 9.5

$ cat /etc/os-release 
NAME="AlmaLinux"
VERSION="9.5 (Teal Serval)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.5"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.5 (Teal Serval)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.5"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.5"
SUPPORT_END=2032-06-01

SUMMARY

When installing from the community repo with GPG checking enabled, dnf fails and reports that the Cloudstack package is using a SHA-1 checksum.

STEPS TO REPRODUCE

1. Install AlmaLinux 9
2. Add Cloudstack repo, enable GPG checking
3. sudo dnf install cloudstack-management fails - see below

I recognize that this is a community repo and not necessarily directly supported by the project. I'm new here, and I wasn't sure where else to send this report. The repos are listed on the official website and installation guide, so I figured this may be a reasonable place to start.

This failure is in line with Red Hat's upstream deprecation of the SHA-1 package hash: https://www.redhat.com/en/blog/rhel-security-sha-1-package-signatures-distrusted-rhel-9. Following the pattern of other repos, I inferred that the presence of a GPG key meant that GPG signatures were available and supported.

EXPECTED RESULTS

Installing Cloudstack via DNF does not yield a deprecated checksum

ACTUAL RESULTS

/etc/yum.repos.d/cloudstack.repo:

[cloudstack]
name=CloudStack EL$releasever
baseurl=http://download.cloudstack.org/el/$releasever/4.20
enabled=1
gpgcheck=1
gpgkey=https://download.cloudstack.org/RPM-GPG-KEY
countme=1
metadata_expire=86400
enabled_metadata=1

Installation attempt:

[user@srv-koana ~]$ sudo dnf install cloudstack-management
....
Dependencies resolved.
====================================================================================================================================================================================================================
 Package                                                             Architecture                       Version                                                        Repository                              Size
====================================================================================================================================================================================================================
Installing:
 cloudstack-management                                               x86_64                             4.20.0.0-1                                                     cloudstack                             1.6 G
Installing dependencies:
....
[SKIPPED] cloudstack-management-4.20.0.0-1.x86_64.rpm: Already downloaded                                                                                                                                          
CloudStack EL9                                                                                                                                                                       10 kB/s | 1.7 kB     00:00    
Importing GPG key 0x584DF93F:
 Userid     : "Rohit Yadav (ShapeBlue Repo) <rohit.yadav@shapeblue.com>"
 Fingerprint: 7203 0CA1 18C1 A275 68B1 37C4 BDF0 E176 584D F93F
 From       : https://download.cloudstack.org/RPM-GPG-KEY
Is this ok [y/N]: y
warning: Signature not supported. Hash algorithm SHA1 not available.
Key import failed (code 2). Failing package is: cloudstack-common-4.20.0.0-1.x86_64
 GPG Keys are configured as: https://download.cloudstack.org/RPM-GPG-KEY
Public key for cloudstack-management-4.20.0.0-1.x86_64.rpm is not installed. Failing package is: cloudstack-management-4.20.0.0-1.x86_64
 GPG Keys are configured as: https://download.cloudstack.org/RPM-GPG-KEY
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
[user@srv-koana ~]$

WORKAROUND RESULTS

Setting gpgcheck=0 or sudo update-crypto-policies --set DEFAULT:SHA1 bypasses the security protocol and allows installation.

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[NuxRo]

The update-crypto-policies workaround is good enough for now, but it does look like RedHat is pushing for better crypto, so switching to a new SHA-256 GPG key would be a good move, but certainly not urgent.

[nf-brentsaner]

This is likely to become an increasingly urgent problem, for what it's worth, as any libraries that use OpenSSL 3.x for GPG signature verification instead of GnuTLS (like RPM/DNF does) may face issues soon; OpenSSL 3.0 deprecated all SHA1 digest functions, with clearly stated intent to remove them.

I should note this isn't the signature of the RPM itself, it's the signature on the key used to sign (the RPM signatures themselves are SHA256, the self-sig on the RPM-GPG-KEY key is SHA1).

If you're using custom crypto policies on EL and/or prefer a scalpel instead of a sledgehammer compared to the above workaround, there unfortunately isn't a crypto-policy scope explicitly for RPM signature verification (yet) but it can at least be scoped explicitly to verifying hashes in OpenSSL (the exact context dnf uses):

1. Create /etc/crypto-policies/policies/modules/SHA1-RPM.pmod: echo 'hash@OpenSSL = SHA1+' > /etc/crypto-policies/policies/modules/SHA1-RPM.pmod
2. Use this specific module instead of the system-wide generic SHA1: update-crypto-policies --set <MY POLICY>:SHA1-RPM (unless using FIPS or a custom policy, <MY POLICY> is likely DEFAULT. For example, if using FIPS, this would be update-crypto-policies --set FIPS:SHA1-RPM. If using a custom policy, the hash@OpenSSL = SHA1+ line may instead be explicitly added to the policy itself.)

When this is fixed, I also recommend using the release.asc key instead of the RPM-GPG-KEY (or creating a new key for all packages); the release.asc key (0x549A7B269985045A6CA8F3343D62B837F100E758, Apache CloudStack <dev@cloudstack.apache.org>) has an RSA4096 key (though its self-signature should be updated, as it too is a SHA1 signature) and was generated late March of 2019 whereas RPM-GPG-KEY (0x72030CA118C1A27568B137C4BDF0E176584DF93F, Rohit Yadav (ShapeBlue Repo) <rohit.yadav@shapeblue.com>) was generated back in late October of 2014 with an RSA2048 key. (Updating/adding a self-signature with a more-recent algorithm should not break existing deployments across various distros, though I recommend testing of course.)

Note that RPMs are still being signed by the latter:

# rpm -qi cloudstack-common | grep -E '^(Version|Signature)\s*:'                                                                                                                            
Version     : 4.20.0.0                                                                                                                                                                                                                        
Signature   : RSA/SHA256, Wed 20 Nov 2024 09:13:57 AM UTC, Key ID bdf0e176584df93f 

Is there any particular reason the RPMs are signed with a completely different, seemingly personal, key?

If generating a new key, I recommend using EdDSA/ed25519/curve25519/ECC for the key (both sign and crypt). It is supported in GnuPG 2.1.0/2.2 (released Nov. 6, 2014) and onwards (and is even the default in newer versions), and to use SHA512 as the default digest algorithm (also the default most-preferred digest in recent versions). This will future-proof for quite some time while keeping compatibility with all supported Linux distributions.

[kpieckiel]

@nf-brentsaner, for what it's worth, I had to name the file SHA1-RPM.pmod (note the 'p' in the extension). Not sure if this is a typo or just a difference between your install and mine (I have a fresh AlmaLinux 9.5 install, latest updates). Mentioning it here for others that may read this and try to implement the commands you gave.

[nf-brentsaner]

@kpieckiel Poor memory more than typo; that was off the top of my head. The .pmod instead of .mod gets me every single time...

.pmod is in fact correct (thank you!) even going back to EL 8.something (if not earlier); I've updated my comment above to reflect this.