nf-brentsaner commented on issue #10133: URL: https://github.com/apache/cloudstack/issues/10133#issuecomment-2574564911
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](https://github.com/apache/cloudstack/issues/10133#issue-2753694483), there unfortunately isn't a crypto-policy scope explicitly for RPM signature verification ([yet](https://issues.redhat.com/browse/RHEL-2734)) 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.mod`: `echo 'hash@OpenSSL = SHA1+' > /etc/crypto-policies/policies/modules/SHA1-RPM.mod` 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 <[email protected]>`) 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) <[email protected]>`) 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
