Description of problem: When using rpm's `-r` option to install into a file system tree root (a.k.a. chroot), the rpm-sequoia crypto policy does not appear to being respected. Version-Release number of selected component (if applicable): rpm-4.18.1-3.fc38.x86_64 How reproducible: 100% Steps to Reproduce: 1. mock -r opensuse-leap-15.4-x86_64 --chroot id (to build a Leap 15.4 chroot which rpm -r will be able to operate in. Note the specification for a Leap 15.4 chroot is due to that distribution still having sha1 signatures on RPM signing keys. mock can be used to easily build such a chroot. You can choose to build the chroot in any manner you wish if you want to use something other than mock.) 2. dnf --installroot /var/lib/mock/opensuse-leap-15.4-x86_64-bootstrap/root/ --releasever=15.4 download libzio1 3. rpm -r /var/lib/mock/opensuse-leap-15.4-x86_64-bootstrap/root/ -i libzio1-1.06-2.20.x86_64.rpm Actual results: error: Verifying a signature using certificate FEAB502539D846DB2C0961CA70AF9E8139DB7C82 (SuSE Package Signing Key <build>): Certificate 70AF9E8139DB7C82 invalid: policy violation because: No binding signature at time 2018-05-25T17:06:36Z error: libzio1-1.06-2.20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 39db7c82: BAD error: libzio1-1.06-2.20.x86_64.rpm cannot be installed Expected results: Package should install as the policy violation noted above is due to a sha1 signature on the key. Additional info: # sq-keyring-linter /usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE Certificate B88B2FD43DBDC284 is not valid under the standard policy: No binding signature at time 2023-05-03T19:19:30Z Certificate B88B2FD43DBDC284 contains a User ID ("openSUSE Project Signing Key <opensuse>") protected by SHA-1 Examined 1 certificate. 0 certificates are invalid and were not linted. (GOOD) 1 certificate was linted. 1 of the 1 certificates (100%) has at least one issue. (BAD) 0 of the linted certificates were revoked. 0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD) 0 of the linted certificates were expired. 1 of the non-revoked linted certificate has at least one non-revoked User ID: 1 has at least one User ID protected by SHA-1. (BAD) 1 has all User IDs protected by SHA-1. (BAD) 0 of the non-revoked linted certificates have at least one non-revoked, live subkey: 0 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (GOOD) 0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey: 0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD) Yet the key is importable on F38, demonstrating that the rpm-sequoia crypto-policy on F38 does allow the key: # rpmkeys --import /usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE # rpm -qi gpg-pubkey-3dbdc284-49144c3f Name : gpg-pubkey Version : 3dbdc284 Release : 49144c3f Architecture: (none) Install Date: Wed May 3 12:28:16 2023 Group : Public Keys Size : 0 License : pubkey Signature : (none) Source RPM : (none) Build Date : Fri Nov 7 14:10:07 2008 Build Host : localhost Packager : openSUSE Project Signing Key <opensuse> Summary : openSUSE Project Signing Key <opensuse> public key Description : -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBEkUTD8BCADWLy5d5IpJedHQQSXkC1VK/oAZlJEeBVpSZjMCn8LiHaI9Wq3G 3Vp6wvsP1b3kssJGzVFNctdXt5tjvOLxvrEfRJuGfqHTKILByqLzkeyWawbFNfSQ 93/8OunfSTXC1Sx3hgsNXQuOrNVKrDAQUqT620/jj94xNIg09bLSxsjN6EeTvyiO mtE9H1J03o9tY6meNL/gcQhxBvwuo205np0JojYBP0pOfN8l9hnIOLkA0yu4ZXig oKOVmf4iTjX4NImIWldT+UaWTO18NWcCrujtgHueytwYLBNV5N0oJIP2VYuLZfSD VYuPllv7c6O2UEOXJsdbQaVuzU1HLocDyipnABEBAAG0NG9wZW5TVVNFIFByb2pl Y3QgU2lnbmluZyBLZXkgPG9wZW5zdXNlQG9wZW5zdXNlLm9yZz6JATwEEwECACYC GwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCU2dN1AUJHR8ElQAKCRC4iy/UPb3C hGQrB/9teCZ3Nt8vHE0SC5NmYMAE1Spcjkzx6M4r4C70AVTMEQh/8BvgmwkKP/qI CWo2vC1hMXRgLg/TnTtFDq7kW+mHsCXmf5OLh2qOWCKi55Vitlf6bmH7n+h34Sha Ei8gAObSpZSF8BzPGl6v0QmEaGKM3O1oUbbB3Z8i6w21CTg7dbU5vGR8Yhi9rNtr hqrPS+q2yftjNbsODagaOUb85ESfQGx/LqoMePD+7MqGpAXjKMZqsEDP0TbxTwSk 4UKnF4zFCYHPLK3y/hSH5SEJwwPY11l6JGdC1Ue8Zzaj7f//axUs/hTC0UZaEE+a 5v4gbqOcigKaFs9Lc3Bj8b/lE10Y =i2TA -----END PGP PUBLIC KEY BLOCK----- If the allowance of the sha1 signature is disallowed by the rpm-sequoia crypto-policy by changing sha1.collision_resistance and sha1.second_preimage_resistance to "never" rpmkeys --import fails: # rpm -e gpg-pubkey-3dbdc284-49144c3f # rpmkeys --import /usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE error: Certificate B88B2FD43DBDC284: Policy rejects B88B2FD43DBDC284: No binding signature at time 2023-05-03T14:41:07Z error: /usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE: key 1 import failed. confirming that the DEFAULT policy should allow use of the key, yet it does not, but it seems, only when trying to operate in a file system tree root. Much of the legwork of getting here was done in https://github.com/rpm-software-management/rpm-sequoia/issues/46 if you want to see more detail.
Chroot has nothing to do with this at all, and here's a simple reproducer on F38 to demonstrate that (if you run in a container, be sure the update the rpm in it first): ``` # curl -O https://ftp.funet.fi/pub/mirrors/download.opensuse.org/distribution/leap/15.4/repo/oss/x86_64/libzio1-1.06-2.20.x86_64.rpm # curl -O https://ftp.funet.fi/pub/mirrors/download.opensuse.org/distribution/leap/15.4/repo/oss/gpg-pubkey-39db7c82-5847eb1f.asc # rpmkeys --import gpg-pubkey-39db7c82-5847eb1f.asc # rpmkeys -Kv libzio1-1.06-2.20.x86_64.rpm libzio1-1.06-2.20.x86_64.rpm: error: Verifying a signature using certificate FEAB502539D846DB2C0961CA70AF9E8139DB7C82 (SuSE Package Signing Key <build>): Certificate 70AF9E8139DB7C82 invalid: policy violation because: No binding signature at time 2018-05-25T17:06:36Z error: Verifying a signature using certificate FEAB502539D846DB2C0961CA70AF9E8139DB7C82 (SuSE Package Signing Key <build>): Certificate 70AF9E8139DB7C82 invalid: policy violation because: No binding signature at time 2018-05-25T17:06:36Z Header V3 RSA/SHA256 Signature, key ID 39db7c82: BAD Header SHA256 digest: OK Header SHA1 digest: OK Payload SHA256 digest: OK V3 RSA/SHA256 Signature, key ID 39db7c82: BAD MD5 digest: OK ``` Import succeeding means little.
The upstream issue seems to have stalled out. No response from inquiries on it. Ultimately this is a blocking issue to being able to use Fedora 38 if it's for the purposes of running mock on it with Leap 15.4. Can we please make some progress is moving this forward to correction?
Hello?
@pmatilai Could you please update here as requested by @prarit? This issue is blocking us from being able to move out systems to F38 and keep them in compliance.
Upstream is the place to sort this out, there will not be any Fedora-specific solution.
Except that (until 2h ago) upstream is not responding and ultimately my issue is with Fedora (as it adopted this change -- perhaps prematurely or without sufficient testing), not upstream. It's Fedora where this is broken for me. But since there is response upstream, I am happy to continue this upstream as long as upstream continues to make forward progress and does not stall out again.
Nobody will be working on any Fedora specific solution to this. That's why the discussion and solution needs to happen upstream. Cross-distro installation such as here is never *guaranteed* to work, due to different compilation and configuration options and patches applied by distros. There's no 24/7 support or guaranteed response times for anything in Fedora, and this isn't anywhere near the top of the priorities in everything that's going on. You'll want to tone it down a bit, and stick to Fedora 37 for the time being if that works for you.
Is https://bugzilla.redhat.com/show_bug.cgi?id=2217961 supposed to resolve this? https://github.com/rpm-software-management/rpm-sequoia/issues/46 says is fixed by https://github.com/rpm-software-management/rpm-sequoia/pull/47. https://github.com/rpm-software-management/rpm-sequoia/pull/47#issuecomment-1609624784 says it was included in rpm-sequoia 1.4.1. But even with rpm-sequoia-1.4.1-1.fc38.x86_64 installed, I am still seeing: error: Verifying a signature using certificate FEAB502539D846DB2C0961CA70AF9E8139DB7C82 (SuSE Package Signing Key <build>): 1. Certificate 70AF9E8139DB7C82 invalid: policy violation because: No binding signature at time 2018-05-25T18:14:58Z 2. Certificate has no valid binding signature as of the signature's creation time, but is valid now. The certificate has probably been stripped or minimized.
https://github.com/rpm-software-management/rpm-sequoia/pull/47 alone wont help with new installs of such content, it only enables a clean upgrade path away from such packages.
So what is the (upstream or otherwise) solution to this specific problem? My upstream report of this issue was closed as solved. Yet it is not solved.