after `dnf system-upgrade` of F38 -> F39, on lsb_release -rd Description: Fedora release 39 (Thirty Nine) Release: 39 with dnf --version 4.18.1 Installed: dnf-0:4.18.1-1.fc39.noarch at Sat 11 Nov 2023 01:38:21 PM GMT Built : Fedora Project at Tue 07 Nov 2023 08:56:26 AM GMT Installed: rpm-0:4.19.0-1.fc39.x86_64 at Sat 11 Nov 2023 01:38:06 PM GMT Built : Fedora Project at Tue 19 Sep 2023 01:02:12 PM GMT exec of any `dnf *` cmd, reports Fedora's GPG key as 'revoked', dnf update DNSSEC extension: Testing already imported keys for their validity. !! DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately Dependencies resolved. Nothing to do. Complete! checking, rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep fedora- gpg-pubkey-12c944d0-5d5156ab Fedora (32) <fedora-32-primary> public key gpg-pubkey-9570ff31-5e3006fb Fedora (33) <fedora-33-primary> public key gpg-pubkey-45719a39-5f2c0192 Fedora (34) <fedora-34-primary> public key gpg-pubkey-9867c58f-601c49ca Fedora (35) <fedora-35-primary> public key gpg-pubkey-38ab71f4-60242b08 Fedora (36) <fedora-36-primary> public key gpg-pubkey-5323552a-6112bcdc Fedora (37) <fedora-37-primary> public key gpg-pubkey-eb10b464-6202d9c6 Fedora (38) <fedora-38-primary> public key gpg-pubkey-18b8e74c-62f2920f Fedora (39) <fedora-39-primary> public key where ls -al /etc/pki/rpm-gpg/*fedora-39* lrwxrwxrwx 1 root root 29 Oct 5 20:00 /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-aarch64 -> RPM-GPG-KEY-fedora-39-primary lrwxrwxrwx 1 root root 29 Oct 5 20:00 /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-ppc64le -> RPM-GPG-KEY-fedora-39-primary -rw-r--r-- 1 root root 1.7K Oct 5 20:00 /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-primary lrwxrwxrwx 1 root root 29 Oct 5 20:00 /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-s390x -> RPM-GPG-KEY-fedora-39-primary lrwxrwxrwx 1 root root 29 Oct 5 20:00 /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-x86_64 -> RPM-GPG-KEY-fedora-39-primary rpm -q --whatprovides /etc/pki/rpm-gpg/*fedora-39* fedora-gpg-keys-39-1.noarch fedora-gpg-keys-39-1.noarch fedora-gpg-keys-39-1.noarch fedora-gpg-keys-39-1.noarch fedora-gpg-keys-39-1.noarch dnf info fedora-gpg-keys-39-1.noarch DNSSEC extension: Testing already imported keys for their validity. DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately Installed Packages Name : fedora-gpg-keys Version : 39 Release : 1 Architecture : noarch Size : 123 k Source : fedora-repos-39-1.src.rpm Repository : @System From repo : fedora Summary : Fedora RPM keys URL : https://fedoraproject.org/ License : MIT Description : This package provides the RPM signature keys. which looks to be the current/latest https://packages.fedoraproject.org/pkgs/fedora-repos/fedora-gpg-keys/fedora-39.html Date Author Change 2023-10-06 Kevin Fenzi <kevin at scrye dot com> - 39-1 - Disable updates_testing for release. fwiw, those keys have only been installed by the system upgrade process; at least, never installed manually by me @ -devel ML, https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IWZHV2ATEPSZT2NLRH3SX5OBFID6QVS5/?sort=date "... Those keys were imported into our dns last may after they were made, and they were working fine then, and nothing in our dns infra has really changed since then that I can recall. So, I suspect a dnf/rpm change somewhere ..." Reproducible: Always
cref, https://www.spinics.net/lists/fedora-devel/msg284969.html & http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signature_using_dnssec/index.html checking w/ '-v', dnf updgrade -v ... Running verification for key with id: fedora-39-primary Key from DNS: b'mQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjyl/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZd/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWfJOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NWs8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hRetbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJUSFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g96tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0LGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33QhysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQABtDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5vcmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBSrcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJwWXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBYB5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrBh/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeftBI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJYZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq445NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc+IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6yJ5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxvA4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FPX55M9nDtzUSayJuEcfFP2c9KQCE=' Input key : b'l/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZd/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWfJOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NWs8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hRetbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJUSFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g96tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0LGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33QhysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQABtDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5vcmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBSrcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJwWXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBYB5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrBh/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeftBI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJYZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq445NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc+IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6yJ5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxvA4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FPX55M9nDtzUSayJuEcfFP2c9KQCE=' DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately ... and rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep fedora-39 gpg-pubkey-18b8e74c-62f2920f Fedora (39) <fedora-39-primary> public key rpm -qi gpg-pubkey-18b8e74c-62f2920f Name : gpg-pubkey Version : 18b8e74c Release : 62f2920f Architecture: (none) Install Date: Sat 11 Nov 2023 07:58:12 AM EST Group : Public Keys Size : 0 License : pubkey Signature : (none) Source RPM : (none) Build Date : Tue 09 Aug 2022 12:57:51 PM EDT Build Host : localhost Packager : Fedora (39) <fedora-39-primary> Summary : Fedora (39) <fedora-39-primary> public key Description : -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy l/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZ d/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWf JOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NW s8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hR etbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ 3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJU SFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g9 6tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0 LGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33Qh ysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQAB tDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5v cmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBS rcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJw WXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBY B5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrB h/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeft BI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJ YZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq4 45NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc +IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6y J5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxv A4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FP X55M9nDtzUSayJuEcfFP2c9KQCE= =J4qZ -----END PGP PUBLIC KEY BLOCK----- note the (relevant?) difference Key from DNS: b'mQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjyl/vjl1iXxucrd2...KQCE=' & Input key : b'l/vjl1iXxucrd2...KQCE=' i.e., a missing, 'mQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy' in the "Input key", as compared to the local & DNS-retreived key
cc'ing msuchy
What is your system clock set to?
> What is your system clock set to? UTC dmesg | grep rtc [ 2.629327] rtc_cmos 00:02: RTC can wake from S4 [ 2.629555] rtc_cmos 00:02: registered as rtc0 [ 2.629587] rtc_cmos 00:02: setting system clock to 2023-11-11T14:44:16 UTC (1699713856) [ 2.629613] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs hwclock --show 2023-11-12 19:55:33.685452-05:00 hwclock --show --localtime 2023-11-13 00:55:38.185353-05:00 timedatectl status Local time: Sun 2023-11-12 19:51:42 EST Universal time: Mon 2023-11-13 00:51:42 UTC RTC time: Mon 2023-11-13 00:51:41 Time zone: America/New_York (EST, -0500) System clock synchronized: yes NTP service: active RTC in local TZ: no timedatectl show Timezone=America/New_York LocalRTC=no CanNTP=yes NTP=yes NTPSynchronized=yes TimeUSec=Sun 2023-11-12 19:51:42 EST RTCTimeUSec=Sun 2023-11-12 19:51:41 EST
A quick workaround: Disable your explicit gpgkey_dns_verification option in /etc/dnf/dnf.conf. It's disabled by default. I will look what's wrong.
The code DNF code seems terribly untested. E.g. I'm getting a Python backtrace some of my gpg-pubkey packages have undefined packager RPM tag.
After massaging the code, I confirm I can reproduce it with python3-dnf-4.18.1-1.fc39.noarch.
Note that it may be somehow relevant to https://bugzilla.redhat.com/show_bug.cgi?id=2142553 but I tried to regenereate the F39 DNSSEC with the amended F39 key, but the DANE record is unchanged.
The warnings reads: # dnf-3 upgrade DNSSEC extension: Testing already imported keys for their validity. DNSSEC extension error (email=): Email address must contain exactly one '@' sign. DNSSEC extension error (email=): Email address must contain exactly one '@' sign. DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately Last metadata expiration check: 3:08:22 ago on Mon 13 Nov 2023 10:35:35 AM CET. Dependencies resolved. Nothing to do. Complete! That's this RPM pseudopackage: # rpm -q gpg-pubkey --qf '%{version}-%{release} %{packager}\n' | grep 'fedora-39-primary' 18b8e74c-62f2920f Fedora (39) <fedora-39-primary> The PGP key in question is: pub rsa4096 2022-08-09 [SCE] E8F23996F23218640CB44CBE75CF5AC418B8E74C uid [ full ] Fedora (39) <fedora-39-primary> <fedora-39-primary> e-mails address translates to "48cb71516f035e33db6249d81d145d8b9198da654fbfbcf16c06104d._openpgpkey.fedoraproject.org" domain. DNS returns: ;; ANSWER SECTION: 48cb71516f035e33db6249d81d145d8b9198da654fbfbcf16c06104d._openpgpkey.fedoraproject.org. 80030 IN OPENPGPKEY mQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhL X6tb9Qjyl/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinA MZBzcyzHcS/JiGHZd/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiC mV0lkZ+khZ4PkVWmk6uZgYWfJOG5wp5TDPnoYXlA4CLb6hu2691aDm9b 99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NWs8Pq2tgyzu8txlWdBXJyAMKl dTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hRetbbwNV+thkLJz0W D90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ3d3q9M09 thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJU SFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWx SWny+9g96tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy 4sARZ4XhTU73Zwk0LGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuH JNSfgrM0BmIBCjhjwGiS33QhysLDWJMdch8lsu1fTmLEFQrOB93oieOJ Q0Ysi5gQY8TOT+oZvVi9pSMJuwARAQABtDFGZWRvcmEgKDM5KSA8ZmVk b3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5vcmc+iQJOBBMBCAA4 FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBS rcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzE HiSb0wJwWXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI 2dGpvTSvohMBMeBYB5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQz eV3F/XdxGhSz/GZUVFVprcrBh/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9 CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeftBI3KWLbyMfRwEtp7xSi17WXb RfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJYZoE53yczemM/1HZ ZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq445NwY01F kSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc +IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnh UDAabV6yJ5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFh BOLhGAnmM5OOSUxvA4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7 npimv3JC+exWEbTLcgvV70FPX55M9nDtzUSayJuEcfFP2c9KQCE= (Spaces inserted by dig tool.) That's parsed by gnugp as: $ gpg --list-packets key # off=0 ctb=99 tag=6 hlen=3 plen=525 :public key packet: version 4, algo 1, created 1660064271, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] keyid: 75CF5AC418B8E74C # off=528 ctb=b4 tag=13 hlen=2 plen=49 :user ID packet: "Fedora (39) <fedora-39-primary>" # off=579 ctb=89 tag=2 hlen=3 plen=590 :signature packet: algo 1, keyid 75CF5AC418B8E74C version 4, created 1660064271, md5len 0, sigclass 0x13 digest algo 8, begin of digest 9d e3 hashed subpkt 33 len 21 (issuer fpr v4 E8F23996F23218640CB44CBE75CF5AC418B8E74C) hashed subpkt 2 len 4 (sig created 2022-08-09) hashed subpkt 27 len 1 (key flags: 0F) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID 75CF5AC418B8E74C) data: [4095 bits] I rather suspect a switch from RPM internal PGP parser to rpm-sequoia which dropped support for binary PGP keys.
> I rather suspect a switch from RPM internal PGP parser to rpm-sequoia which dropped support for binary PGP keys. The internal parser only ever supported ASCII armored keys, not binary. Sequoia technically supports both, rpm-sequoia may disable binary for compatibility reasons (but I don't remember).
for those interested in the read, "RPM Sequoia: A Sequoia-based backend for the RPM Package Manager" https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/
Looking at dnssec.py, it's not obvious to me that rpm's crypto (PGP or otherwise) is involved at all, the only rpm involvement I see is pulling the ASCII armored keys from the db.
> DNSSEC extension error (email=): Email address must contain exactly one '@' sign. How this can happened? The code https://github.com/rpm-software-management/dnf/blob/master/dnf/dnssec.py#L59 and the email in question has only one @. The code in question about revoked keys is https://github.com/rpm-software-management/dnf/blob/master/dnf/dnssec.py#L159 I wonder what it prints with log.debug enabled?
> tried to regenereate the F39 DNSSEC here, diff -us /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-primary /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary !! Files /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-39-primary and /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary are identical it's the difference between the "Key from DNS" from "Input Key" that looks a problem, in /usr/lib/python3.12/site-packages/dnf/dnssec.py ... @staticmethod def _cache_miss(input_key): # type: (KeyInfo) -> Validity """ In case the key was not found in the cache, create an Unbound context and contact the DNS system """ try: import unbound ... !! status, result = ctx.resolve(email2location(input_key.email), RR_TYPE_OPENPGPKEY, unbound.RR_CLASS_IN) ... else: data = result.data.as_raw_data()[0] dns_data_b64 = base64.b64encode(data) !! if dns_data_b64 == input_key.key: return Validity.VALID else: # In case it is different, print the keys for further examination in debug mode logger.debug("Key from DNS: {}".format(dns_data_b64)) logger.debug("Input key : {}".format(input_key.key)) 159 return Validity.REVOKED ...
I verified that it's not caused by rpm-sequoia. I get the same warning when using rpm built with OpenSSL.
(In reply to Miroslav Suchý from comment #13) > > DNSSEC extension error (email=): Email address must contain exactly one '@' sign. > > How this can happened? The code > https://github.com/rpm-software-management/dnf/blob/master/dnf/dnssec.py#L59 > and the email in question has only one @. > That's the problem I described in comment #6. I have gpg-pubkey-e8e40fde-4b563cdc in RPM database. It's a key for Fedora 13 and it has no packager RPM tag. Current code crashes on it. So I locally faked the e-mail address to an empty string. I will fix it later.
It is as pgnd wrote. The code simply compares a PGP packets block from DNF with that from an RPM database bit by bit. That's utterly insufficient. A PGP block can contain additional signatures, revocation certificates, subkeys, etc. All that changes a binary representation of the PGP block while the key itself remains unchanged.
fyi on one machine, i added two repos cd /etc/yum.repos.d cat brave-browser-rpm-release.s3.brave.com_x86_64_.repo [brave-browser-rpm-release.s3.brave.com_x86_64_] name=created by dnf config-manager from https://brave-browser-rpm-release.s3.brave.com/x86_64/ baseurl=https://brave-browser-rpm-release.s3.brave.com/x86_64/ enabled=1 repo_gpgcheck=0 cat vivaldi-fedora.repo [vivaldi] name=vivaldi enabled=1 baseurl=https://repo.vivaldi.com/archive/rpm/$basearch gpgcheck=1 gpgkey=https://repo.vivaldi.com/archive/linux_signing_key.pub now, dnf update DNSSEC extension: Testing already imported keys for their validity. DNSSEC extension: GPG Key packager has been revoked and should be removed immediately DNSSEC extension: GPG Key support has been revoked and should be removed immediately DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately ... the issue is not unique to the Fedora key ...
I think I found the bug: It's an off-by-one error in parsing gpg-pubkes description in /usr/lib/python3.12/site-packages/dnf/dnssec.py: def _query_db_for_gpg_keys(): # type: () -> List[KeyInfo] # TODO: base.conf.installroot ?? -----------------------\ transaction_set = dnf.rpm.transaction.TransactionWrapper() packages = transaction_set.dbMatch("name", "gpg-pubkey") return_list = [] for pkg in packages: packager = dnf.rpm.getheader(pkg, 'packager') email = re.search('<(.*@.*)>', packager).group(1) description = dnf.rpm.getheader(pkg, 'description') → key_lines = description.split('\n')[3:-3] key_str = ''.join(key_lines) return_list += [KeyInfo(email, key_str.encode('ascii'))] return return_list There should be 2 instead of 3. Python counts items from 0: key_lines = description.split('\n')[2:-3] It attempts to obtain the Base64-encoded lines from a description RPM tag. E.g. it should extract "mQI..." to "X55M9nDtzUSayJuEcfFP2c9KQCE=" lines: $ rpm -q gpg-pubkey-18b8e74c-62f2920f --qf '%{description}' -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy l/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZ d/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWf JOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NW s8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hR etbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ 3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJU SFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g9 6tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0 LGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33Qh ysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQAB tDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5v cmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBS rcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJw WXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBY B5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrB h/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeft BI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJ YZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq4 45NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc +IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6y J5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxv A4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FP X55M9nDtzUSayJuEcfFP2c9KQCE= =J4qZ -----END PGP PUBLIC KEY BLOCK----- But it always started from the next line "l/vjl...". That can be seen in a debug mode (dnf -d 10 ...) where it reports the misparsed in-database key as "Input key" value. The bug was there since the very beginning (after 3.6.1 version). Maybe your DNS resolver now forwards an AD bit (DNSSec validation passed) and thus DNF started to consider the DNS answers. Without working DNSSec, the keys retrieved from DNS are ignored.
off-by-one errors. fun! > Maybe your DNS resolver now forwards an AD bit (DNSSec validation passed) and thus DNF started to consider the DNS answers. Without working DNSSec, the keys retrieved from DNS are ignored. my local resolver is named BIND 9.18.19 it's been set up for DNSSEC service for ages; *afaict*, well-behaved. all other resolvers across the org are either also bind9.18.19 or unbound1.19.0, in all cases DNSSEC ready. fwiw, here, dig TXT 48cb71516f035e33db6249d81d145d8b9198da654fbfbcf16c06104d._openpgpkey.fedoraproject.org +dnssec ; <<>> DiG 9.18.19 <<>> TXT 48cb71516f035e33db6249d81d145d8b9198da654fbfbcf16c06104d._openpgpkey.fedoraproject.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15205 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: d99c74a510f1c90101000000655266d472fc6c90b06afa83 (good) ;; QUESTION SECTION: ;48cb71516f035e33db6249d81d145d8b9198da654fbfbcf16c06104d._openpgpkey.fedoraproject.org. IN TXT ;; AUTHORITY SECTION: _openpgpkey.fedoraproject.org. 10534 IN SOA ns-iad01.fedoraproject.org. hostmaster.fedoraproject.org. 2023111300 3600 600 1000000 10800 _openpgpkey.fedoraproject.org. 10534 IN RRSIG SOA 8 3 86400 20231213102046 20231113102046 57393 _openpgpkey.fedoraproject.org. XMS+EdtuSaS1TBXBDrJFjw8irye4DFXD+vtPrvFWNtpFasFJ0b4MpMaP y7YJs1LL4QMnBVa+rZL6WedXCdUb+JBnzSex4qN+e0cFd9rCjIUkUJgS v51vIAxMPDtu2lN3EgI2AmaXhN1GZNYiwKlrOqfYmJydg2Fi7fkFFRrs 1uE= 48cb71516f035e33db6249d81d145d8b9198da654fbfbcf16c06104d._openpgpkey.fedoraproject.org. 10534 IN NSEC 48d2096db9a1a54a46ffa56bf14b604123ed0fa582c6e1517f3c9730._openpgpkey.fedoraproject.org. RRSIG NSEC OPENPGPKEY 48cb71516f035e33db6249d81d145d8b9198da654fbfbcf16c06104d._openpgpkey.fedoraproject.org. 10534 IN RRSIG NSEC 8 4 10800 20231213102046 20231113102046 57393 _openpgpkey.fedoraproject.org. qzN4OPht6t3zv12Xq4KiVjeLnwkVwT2JUM0KwZ1KadAsxgOHA8qqVmjt DUR1+48bWo7Tk8F8nChJXjrt6zxmW8A3H4g167zEvjnV0vzJaf5vjkQ1 s4IB73Jra9cjv6BcrJsygrB8nLnkVJawZAGRxQSJC+rtIBxynyhLcWHo /ME= ;; Query time: 0 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Mon Nov 13 13:11:32 EST 2023 ;; MSG SIZE rcvd: 704
confirming, dnf update DNSSEC extension: Testing already imported keys for their validity. !! DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately Fedora 39 - x86_64 81 kB/s | 21 kB 00:00 Fedora 39 openh264 (From Cisco) - x86_64 3.6 kB/s | 989 B 00:00 Fedora 39 - x86_64 - Updates 67 kB/s | 23 kB 00:00 ... Dependencies resolved. Nothing to do. Complete! edit /usr/lib/python3.12/site-packages/dnf/dnssec.py ... 267 @staticmethod def _query_db_for_gpg_keys(): # type: () -> List[KeyInfo] # TODO: base.conf.installroot ?? -----------------------\ transaction_set = dnf.rpm.transaction.TransactionWrapper() packages = transaction_set.dbMatch("name", "gpg-pubkey") return_list = [] for pkg in packages: packager = dnf.rpm.getheader(pkg, 'packager') email = re.search('<(.*@.*)>', packager).group(1) description = dnf.rpm.getheader(pkg, 'description') - key_lines = description.split('\n')[3:-3] + key_lines = description.split('\n')[2:-3] key_str = ''.join(key_lines) return_list += [KeyInfo(email, key_str.encode('ascii'))] return return_list ... dnf update DNSSEC extension: Testing already imported keys for their validity. Fedora 39 - x86_64 81 kB/s | 21 kB 00:00 Fedora 39 openh264 (From Cisco) - x86_64 3.6 kB/s | 989 B 00:00 Fedora 39 - x86_64 - Updates 67 kB/s | 23 kB 00:00 ... Dependencies resolved. Nothing to do. Complete! not clear what other effects that has does raise the question of how a 'REVOKED' key status is dealt with. clearly, it report(ed) as 'REVOKED' during the upgrade process ignoring that it was, apparently, an incorrect assessment -- shouldn't a REVOKED key have caused a pause, or fail, in the upgrade/install process?
I checked Fedora 38 key and there the bad line index "3" is correct: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: rpm-4.18.0-beta1 mQINBGIC2cYBEADJye1aE0AR17qwj6wsHWlCQlcihmqkL8s4gbOk1IevBbH4iXJx While Fedora 39 key is missing the "Version:" armor header and thus index "2" is required: -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy l/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZ That's why the reported behavior started with an upgrade to Fedora 39. So the PGP armor message message will have to be improved differently. How the REVOKED status is determined? DNF queries DNS for a key matching an e-mail address of the locally installed key. Only if a record in DNS exists and the record bit-by-bit differs from the local key, then DNF reports the key is revoked. An experimental RFC 7929 this DNF code tries to implement is not much explicit about determining a revocation status. The closest statement is "Confirming that an OpenPGP Key is Current" section <https://datatracker.ietf.org/doc/html/rfc7929#section-5.2> . It reads: If the locally stored OpenPGP public key is different from the DNSSEC-validated OpenPGP public key currently published in DNS, the confirmation MUST be treated as a failure unless the locally stored OpenPGP key signed the newly published OpenPGP public key found in DNS. An application that can interact with the user MAY ask the user for guidance; otherwise, the application will have to apply local policy. dnf.conf(5) documents, that in interactive mode all the DNS checks are advisory, warnings. But they do not prevent the program from continuing. On the other hand, it documents that in batch mode it can automatically importing a key. However, that happens even without DNS checks, and I did not find a DNS code which would actually meddle with the imported keys.
i checked the case for both index "2" & "3" for the additional repos' (brave & vivaldi, as in example above) keycheck fails. although the Fedora key fail *is* resolved by using index "2", the other repos are NOT -- they still report fails in either case. sounds like it might be yet a *different* header count used by them ... thx for the info/link re: the check/fail policy it seems unwise, in batch mode and *particularly* during an OS system upgrade, to automatically import/pass a REVOKED key application of 7929 policy sounds like it'd address that.
I developed a fix <https://github.com/rpm-software-management/dnf/pull/2019>. With that patch Vivaldi key is not reported as revoked. In debugging mode it correctly prints that there is no Vivald i key in DNS.
here, dnf update DNSSEC extension: Testing already imported keys for their validity. DNSSEC extension: GPG Key packager has been revoked and should be removed immediately DNSSEC extension: GPG Key support has been revoked and should be removed immediately DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately Dependencies resolved. Nothing to do. Complete! cd /usr/lib/python3.12/site-packages wget https://patch-diff.githubusercontent.com/raw/rpm-software-management/dnf/pull/2019.diff -O ~/patch1.txt patch -p1 < ~/patch1.txt patching file dnf/dnssec.py dnf update DNSSEC extension: Testing already imported keys for their validity. !! DNSSEC extension: GPG Key packager has been revoked and should be removed immediately !! DNSSEC extension: GPG Key support has been revoked and should be removed immediately Last metadata expiration check: 0:02:07 ago on Tue 14 Nov 2023 10:11:44 AM EST. Dependencies resolved. Nothing to do. Complete! dnf update -d 10 ... Running verification for key with id: brave-linux-release Non-existence of this record was proven by DNSSEC DNSSEC extension: GPG Key brave-linux-release does not support DNS verification Running verification for key with id: support Non-existence of this record was proven by DNSSEC DNSSEC extension: GPG Key support does not support DNS verification Running verification for key with id: brave-linux-pre-release Non-existence of this record was proven by DNSSEC DNSSEC extension: GPG Key brave-linux-pre-release does not support DNS verification Running verification for key with id: packager Non-existence of this record was proven by DNSSEC DNSSEC extension: GPG Key packager does not support DNS verification Running verification for key with id: packager Key in cache: <dnf.dnssec.NoKey object at 0x7f61448314c0> Input key : b'mQINBGO9ZysBEACeLmXsTfEk6Msqskhkr+fU2uFTinefc6o8p1T9uRVkBiIM641/n76LtmGuGQkIsDi+a6XkdNE08hn8IHru3Ir5m2/oku8lP99U0iHjKpF6D/37xxJa5w9NyOQwusd3p4mPY+QB284ngMPPKIO0dudCfnRAPNzZejSwJ/rqoakMpBSPLn6jU4la52aCfa25dtz2xpE6Q7mAvmi/zX/33ZdY71fJdoALXduQCLOMHj4i7J3BR8uQcC9KdJCm2DfaZAL2hz7+U8PeNkd7JOaKV+0nNYUhTN9zfE52vZq3SYWbCmBxlW7hN+djIVtn85z/9xZX9fhDA8FKxIqL7SThPGZa/M4K7k+hlDxlZ3qhUCOfSN8L0zbk/3iFb8K7h5YJbg5W5Cmm6bGQHPS9Urb2pAPaXn65fZYTEyGq0KN2aely4bq+HisKa0N+aqrFeslCa2fJHom2BNle+Yy4Ys18xZ+I8Fji7HGQ6y8PcivaOw29R7Cspn/NJEVZeR/jPXXylB0jf2zN1tOj7PKKvW3n6I6i3zd69OepkV/hBD9xLUqb0M+QSRGQ3CMPCCvJA3A5D2UfPY+DSZNMkYG+p97mNEVqgOgBHZzz4wKTK92zF2GcvcdEsqtdukcQ9w/gLVU3Vv5KDUAB23wIqm1Jdo3JXRqZge5f2/EV41rVI7vRx63GdQARAQABtDVWaXZhbGRpIFBhY2thZ2UgQ29tcG9zZXIgS0VZMDkgPHBhY2thZ2VyQHZpdmFsZGkuY29tPokCVAQTAQoAPhYhBDNgGPJj+gAAZc7XxhJPFJgz6quOBQJjvWcrAhsDBQkEBFIABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBJPFJgz6quOQJsP/AqbnLZAO9C3Hmljz0O5B+Ms2FXMVM/KF9DwIdV+AIiwf/WloPRbomYKapTRYIhPsQOUOl2C1IvSp3Em2fQM6dtMPzDDs7NkY0wGOVBHWVHeaXinxcPaZUY4Jd+QKsI0q3sdNJcVMuX60/+cmJ2nzNZNfdxAmcXl2g9/QJpBXyrgTHS4C2EtvkhdEFHvUzg28ne85WFsNDVGJqiNpgS+GFbL9lxxHBe5KDZBnJXzURnvS63CnbbZiP5mHk0Xp7849yF13WYZYI5L6aZjpAxExpz6hyKz8TLLcCdB+lV98PYlJBSR556dmmR27xCiYjgIYdY2HhjdwrJN9ARz5RNdFUsne0JXIoFwR8UI6rBPh7dLhQGg9FU5K4ACrcItksnlgc7S9a9qTBZUhY9pqAS2hn1xKYbNo7xTV2z+afYsvkrv68SuEEOngMLDGNA/i/zUI541XuJ1htMVDRTEmbApJapEfDr0Y0YoiCfVaTor5YxJw6eO6SC4+TCfcKNsmSwHkj+irVcliWNCs0MoUUhthRbKwdPndQgvGioCHFz+KfHOuPK/RAoMrriKxAw1pBTjG8Y0zWzMKaMTBH7AkHzkT0qXjZhEFEaSFLFJa1OSKQNoodqxOGCDI/JEPvz8kXIAKcGV1yPctq/EQJJGP3SyqnQON8sYaog3I4xuwLCpO+UduQINBGO9ZysBEACYB6sAsXwUdBUWjQgWBvx5Sb3K/yrk9+Wj4ahdHOhFFtH//xI1170Jeac3iFONUJJ69dBwOY8IrPtpsl8pz+/Sr0+4cqyR5whkxuRAqqMKI47F+Voi/I931T4pV8fNcz5Y5rZaEkfxfUFl6mkGdKzVBdlxkbdcTSFr5gIb0UYQvRc9TzsNO9OFly6sR9Iz/T4h5S7/k1qagpiVJeT6il2QiY2OBhSUfmlvBItadCD4ZrFvFeNREyDQ7xJ/mU46R39AGTtqt1QmuSdCO1+z6JSToD9x6xv/eF5uLbvztogj9yEw3t8AubRT253dMLLfHm8lnYdC8GwFel9L0+s5ex2Dj4xyxZosV3dwQXk/oaHefW9BjcQLxGkOH0gBt+ZQ+mHUlI4kgOXQguHKuCrBycT5DyrrbQbPFp3kQXbLzKNym7eWHnbvZx6uIQSu70QvBo9zPRiurC7A4ofKcpvJdRhbojmc9ekprM2hDZEcsyiT0t/6W8+zfxyGBLK4pLMkuhGB8VQV+U7WvIxkRQLqpzo0nzEEOkxxBSI+O6hLDeZVOLBhuLW49K1E2zfDp6PWoDMEccT684+ZPvz/ytVr3jBYHkaMH4Djzxl/BuSMA+njljpzjPvdpjSsCQ753IyqudXQ1aVscfrrI31OB1JVAjCyziBpGVyNlOjVpYukWLoReQARAQABiQI8BBgBCgAmFiEEM2AY8mP6AABlztfGEk8UmDPqq44FAmO9ZysCGwwFCQQEUgAACgkQEk8UmDPqq44Jkg/9F2rupFszfK9Qes8lMZ/7bqMZam45cIYURQY+6BJ8yqvj8u3we/uiGb0dwF+zOt4TkJU+U7bqNEyB4pZsOoAQlYA/YPa4y0jTTJKFdjnKIXo/LaqKz8Mc7ONpOZHGZ25MGL+/vxMYX2Pi0dNGsyqFBXRwuSs1Mx0sJunFf/qyIfwC3CCf6TWlAfCMNlNhoQ4idNmGQ4hZq0BZFROjNKKuOm+Dm6qYo6VDjP/C+ttgo+N+kydq6Ieytbecys+aQBSFstuJilhj9sRVmFDEze6Q4D2Q5dnuuT3ZET0U1aQ4KOcCUnPA5xrEb/iB/W3n76A/IS+42XHIwU8KgpQGMOegE1L9KSX9/ps1BEu1C9z10MmUZBchKydoSJBbTZKh+7+aixsK7ruWpgU6qLxx+dqTZ7CF55m6JxAwrbbamSFfW91NA4yoNAMtkDx5KP9/fLoVnZumB6LrSiXbD+mMJ/IqGpFSSH95EjLJO0c8U49MbQVgB5aHgt50k9sq8HtoJ7ewpEmTsz4xGk7qg09h2SBhBWpiol7i3S96n8BdZOzpjBM0ZBu41foC9r2WFxJhs/vEnlqaWFyoci3Fngd2+eymsme2AoQi0vHVYcLcL/0HjbU+f/5Cv0YFgj0mvoqFB+IG/ALHKLjnVlvK3NkBqWBEmDSNS2yMqMM3KjvpwATqCUA=' DNSSEC extension: GPG Key packager has been revoked and should be removed immediately Running verification for key with id: support Key in cache: <dnf.dnssec.NoKey object at 0x7f61446d01d0> Input key : b'mQINBFvFEDIBEADwix8cI/QMI36OjLMpL/2xX4D4JYHZdqwja8xRRoQ7lnw2w+zvGnyksvyL6ycEWVw06awzUq+q2/YYNMpWg3zGwuELLytMLMjZ/Y2A57ArA+JH+1b2upKiOnvzStTsoh2Tpt3ob4AHlgua37ZqtrLaFjzlQGVuTA2aqA6kWsJuLBPy4Zkeyl1i3JwfAjNfhQDYpniwG6a4wEui8GQJX5GvBGtctLU+aHflSFqvoLtRP2UVDApEUaoqK/oil54mEUpQBkD7S619GQLNh1PWnHwlO0K2fGGZxiIY8RpplN4GgSSzFZ11BQE3DzaXL8E7O1+dIBnuAdaMVheWAH23mRIrUCKOpaYJGy4JLhhfrjPo34F+8ruKk57cFHgZMc/N2il2eXYtMrgPKCJCNAr3XBhiVDj0x+InSwK19V/fjTSUJsM+Ru18NgL4+XeeBJHCDWOG9b4Z/94+d0KBwDuxyY4TIFgZ817dUXxM4RKh8IIWaIufgWcTCbB6aYZGdCBn8trSisIdCfMdhL4bUQ/AzfO0EygQ7PonFN5EUSpfV8EGbCjt6MVqnPUdiVndC6PgKwg5ox8ZOlHhXCtZsqZc8Qq5JT3j1RVKVHc/HqwJhRI529/EOp3N7Pfl6FbjqlVzQM97cUIOZUvzPIG9Y6qDoT54pKltGV5OqmeOEuPzmslwIQARAQABtCJCcmF2ZSBTb2Z0d2FyZSA8c3VwcG9ydEBicmF2ZS5jb20+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEE2LrU3n7hevUqg0stC7dYKcLU6CEFAmRb1zoFCQ46YYgACgkQC7dYKcLU6CGfkA//TKV8nQIiTtvdCdfB3llU2ghjzAkD1bO5rjXG6bRl7PvKdDJy66LNmjssV+WbGc8eSfhRAOY95oLQTBXM7Xlh+Di8U1ywRsGCfn/j6WMpmkY1Ww0PSNpABsq5uwUzPcT10ToeMJsrPKFqy9YUYkB2rEgLJ5eqWuGfTb8EcgjzzpYD1d/AfCgpvkAIOr9lScyNavbZNyBr+XBCXxcXGldTtC35vMSIMJASQNFpPtF39xzTmpUiZpI1v7ne52dcm8+Hda6ZGJ9gjoE+FIILLPzxd5EMmgfbZLxTlkfJsQgGvf6f/5U0jOAe4KyNno6LKk64JasRL3Yzrmp9rkb1R+2J4318LmeuhWZjfu7OJzFS2AB/Hv+QkfFz4RIJerEDXRYA2FnziJi9IJb/vEltqIZAQk0ys0i1TTPWBASik00lL5gsQLrQjHbNZsgnqE/1kWxlGYTny7RGIE5qj0MrL3rDTUNaF3wVK8KclttQnfCaqHhaOsuEV8+xw/vFBXd4F1vUxz0BuCrj8xzh73ucMKB+MVW4EdhsV5UU1lLTlmTKmULtPEKHImJn5OuiZeZn53sXiF3s+8DKwNXKU3XMP3zZq9BJPxw8TNTAaQn0xAQd0q7qBnwgMtoPo37PTeuVnwMR9O3X53QKpzrP1l8bJzcl+azvZbDElEUpGWzqeonV+HO5Ag0EXai0nAEQAMt19Vv96p6Qp2Oo6h0axShUqqYhHLe/HzHUQJwoggirU4e6CNH1D8de/6/Wy/QsbGVyYpsxliog7sNbGXp4T8UowY8dHDN4z+7+6MSSthYrs/zlyml/shDvCFuve6LpZuOCVlOruax+v3NbaDoQDQYEKDku3ggv7J1GIP+LbIGvzVe62Q/Bqrgblnr+NByaWHAyNbo1v/GfLcp2Ltxn6j0bmVY4I3uYi1Auxeo5KbCBwh0FZTDMbO8t+H5cSuNsqoN/EZcELGabiRysKt7z9YVNkyyhZZp5v3QPDlhhAb4+T8g2fll/JXMUdcR3WGkwOBf94XOdIVvRUoiCXeW+iOsZ70onJGVHxwXgawfGmm73KfwD5c8YHrOYTSUkIaAhB+czkMNPoSQ7f4sTaROyu/Rnv2s27cHxg570LGbVyGboEQK60y/gWRYTmS3+/YfOFn7vrNdWCcDUOKrDgl4lXSeQ76sTLOG7P+sUOlrUh/eUAkxANrvzfY59U2xsqxBhfcm3/zBHfvXv44h15uoqfukxZudq35knTWMqN/x97h9hQ26vVsjX8UzcDCjJ5KzrSKLE1Qtu3t5gD10Rue7kk4iCsXwvrYPQIcEaYi3hzW+rjCxkGcaGpZtS0JuMoTgxoUA1s9XOu916sF2vuMdnPipx8/OsaYUEVQCdsPwlAUOdABEBAAGJBHIEGAEKACYCGwIWIQTYutTefuF69SqDSy0Lt1gpwtToIQUCZFvXYQUJCnWJxQJAwXQgBBkBCgAdFiEEm9GYothIxILjVQaXqFgL3ILT3GwFAl2otJwACgkQqFgL3ILT3Gxz+RAAl7EichPIEFgk9JmenhwGWPxRF59NEWExluAGY/wiyfqLg7SVxowNrZOSdUgxZvKqEoAarsFtdmnG5mrIOMCd3MmJvm2EVbQbDFGF2ojRpaP2NefO5Au5nHqu0j0TM0NelSukGOK66MAuzu2SWKMNArfuKoBEXbaS57uVf0+t/kg9z4ga9mwBOyXfCi9eceAbrY/oJaXjGHoZk5hnShL8m0I9cHnG044Kps8/8lQ8R5ELcdb5b8xYfR4oVIT2t/QmvTE8AhibO9//+MCHejWSF3K3EsF7Dwr8INCO+AThYZNYth1szpVNkcd4FyYj956wRD3vAzrpV7lzwyTJ6jsa/L6fYELhrA+b2m90kT3F8+PUe/jglyjnfFShDrglb4X2RP3AkYSQLkCl5Bk4sB79wTNUJ0GZp7ZLlHfddIa3bPwZhtLN1xop0emxvHy0xc5MiOJiDLT6BpqaPomSUVIrw/WUt7zwKwbOA9qD5WFMirX6H5lmSkYj8gtTEqQXn2JUridyYqoJeQldCDPql/LEC2rdInld1dBrd+maVjauRvx5m4B7LCbWLtEOAfSDGxYU5Sj3LM8X6z/p3TMwBZvp44d8VkkI9NFqutInaLE6iMwWVqD3uSp5WeWom9iTENfHzpMC7q1eOckRb+PZdTLJ4BUys++iYCTnjHEFBI2riSAJEAu3WCnC1OghrkcQANKH9KeTBLLTm5UiwnIVapwAfPsYfqOehhiJW4hBugXXFO/vORuQ9UGt5MF3l1fv7Y9IbA+lEHp8bK9qe47AXPJoM5dEFn2aLcCwztmqDKaTIbotrF/tYYt2/8qnGmkMrc6tT9Atl0ZBmjtE074x5qJfp4JwCUdiRz63UAc3JIRCAs+HquSz7k1QpxeyMQBNsLqn1W5o8FOymprIiiCMqL1Xqa8AYqcQlPlrSyFTa3i4BVyE9t5GNZv0RMRdxU75zOCHg9tG2CFofWzGyKIq8N6aRsNxqMBU2CLJZqqKM79bShwhSlkd9WjX2HtkpPe4iP2oyPCEN1KKrd0Vtr56U8SFwabY6wxBRBACVXDOMBdrh3EkYTY34ySfQw8rzJ8D/CeWzhAQvtxPPWCkdeTDNBMVqiKioLd6J45U3syqppLK3tQewfP7LJIIk6DMDaiGrT/FEp5WB/8pRN9iC/UsyV+KyxqXnxNjD0Uw0J3JADRpJ09Or8Aox6CYNzM9+06OIUzkg+Yzynig6jh6VIqEC85y5KiEaiK5CGlT4v0yXvEtIJBvXuTneNGu7oMUXQhbRtWPKVTnkKUQHcE4F4mcDcFZL2HkRereKIXiu/40Sdqzaoj1PhTGQftfSepVCTFkdEVRNbjRV6548kcrbfVqB+7ZOK4UCu/iceQM8OkiDCU+' DNSSEC extension: GPG Key support has been revoked and should be removed immediately ...
I see. You probably have multiple keys for "packager" in RPM database. The first key is correctly processed and the resolution is cached. The second key is correctly recognized as cached, but then when checking the cached value for this-key-does-not-exist-in-DNS value (NoKey() object in the code), the check is incorrectly evaluated as the-key-exist-in-DNS and a key mismatch, thus revoked warning is printed. I'm not an expert in Python, but it looks like a constructor for a class without any attributes (NoKey()) returns a new instance every time. That can be seen in your log where "Key in cache: <dnf.dnssec.NoKey object at 0x...>" shows different addresses even in the same DNF process. Then comparing with "is NoKey" never matches. I guess an author of the code wanted to use a singleton. Or he should use "== NoKey()" comparison instead, or "isinstance(..., NoKey)", or use None instead of a special NoKey class. I will try to fix this another bug. (Your test also reveals that the code does not support multiple keys in DNS for the same e-mail address.)
I placed a third commit in the pull request which should fix your problem with multiple keys for the same address.
it does appear atm a bit of a mess rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "vivaldi|brave" gpg-pubkey-20038257-63ab09c9 Brave Linux Release (Brave Linux Release) <brave-linux-release> public key gpg-pubkey-6a8a26f9-5b4e234c Brave Software (Brave Core Nightly Key) (We're reinventing the browser as a user-first platform for speed and privacy.) <support> public key gpg-pubkey-f661cdcb-63ab09ad Brave Linux Pre Release (Brave Linux Pre Release) <brave-linux-pre-release> public key gpg-pubkey-4218647e-61f7b089 Vivaldi Package Composer KEY08 <packager> public key gpg-pubkey-33eaab8e-63bd672b Vivaldi Package Composer KEY09 <packager> public key gpg-pubkey-c2d4e821-5bc51032 Brave Software <support> public key for k in $( rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "vivaldi|brave" | awk '{print $1}') do echo ${k} rpm -e ${k} done rm -rf /var/cache/dnf/{vivaldi,brave}* rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "vivaldi|brave" (empty) dnf clean all dnf update DNSSEC extension: Testing already imported keys for their validity. ... vivaldi 3.2 kB/s | 833 B 00:00 vivaldi 65 kB/s | 3.1 kB 00:00 Importing GPG key 0x4218647E: Userid : "Vivaldi Package Composer KEY08 <packager>" Fingerprint: DF44 CF0E 1930 9195 C106 9AFE 6299 3C72 4218 647E From : https://repo.vivaldi.com/archive/linux_signing_key.pub Is this ok [y/N]: y vivaldi 199 kB/s | 31 kB 00:00 ... rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "vivaldi|brave" (empty) dnf reinstall vivaldi-stable brave-browser brave-keyring ... DNSSEC extension: Key for user packager has unknown status. Importing GPG key 0x4218647E: Userid : "Vivaldi Package Composer KEY08 <packager>" Fingerprint: DF44 CF0E 1930 9195 C106 9AFE 6299 3C72 4218 647E From : https://repo.vivaldi.com/archive/linux_signing_key.pub NOT verified using DNS record. Is this ok [y/N]:y Key imported successfully Public key for brave-browser-1.60.114-1.x86_64.rpm is not installed Public key for brave-keyring-1.14-1.noarch.rpm is not installed 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 rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "vivaldi|brave" gpg-pubkey-4218647e-61f7b089 Vivaldi Package Composer KEY08 <packager> public key i've never manually added the vivaldi/brave keys; i *do* see regular updates from the repos ... dnf history list vivaldi-stable | head -n 10 ID | Command line | Date and time | Action(s) | Altered ---------------------------------------------------------------------------------------------------------------------- 2620 | update --refresh | 2023-11-09 08:10 | Upgrade | 10 < 2609 | update --refresh | 2023-11-02 11:24 | Upgrade | 1 >< 2584 | update --refresh | 2023-10-26 07:19 | C, E, I, U | 24 >< 2540 | update --refresh | 2023-10-06 14:16 | I, U | 170 >< 2528 | update --refresh | 2023-09-28 15:01 | Upgrade | 1 >< 2514 | update --refresh | 2023-09-22 17:29 | Upgrade | 2 >< 2511 | update --refresh | 2023-09-21 15:03 | C, E, I, U | 301 >E 2510 | update --refresh | 2023-09-07 05:55 | C, E, I, U | 42 E< dnf history list brave-browser | head -n 10 ID | Command line | Date and time | Action(s) | Altered ---------------------------------------------------------------------------------------------------------------------- 2620 | update --refresh | 2023-11-09 08:10 | Upgrade | 10 < 2610 | update --refresh | 2023-11-02 17:04 | Upgrade | 2 >< 2583 | update --refresh | 2023-10-25 18:43 | Upgrade | 1 >< 2560 | update --refresh | 2023-10-18 19:07 | Upgrade | 2 >< 2550 | update --refresh | 2023-10-11 15:41 | Upgrade | 5 >< 2538 | update --refresh | 2023-10-04 15:55 | Upgrade | 16 >< 2529 | update --refresh | 2023-09-29 05:56 | Upgrade | 1 >< 2514 | update --refresh | 2023-09-22 17:29 | Upgrade | 2 ><
(In reply to Petr Pisar from comment #27) > I placed a third commit in the pull request which should fix your problem > with multiple keys for the same address. confirming, rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "vivaldi|brave" gpg-pubkey-20038257-63ab09c9 Brave Linux Release (Brave Linux Release) <brave-linux-release> public key gpg-pubkey-6a8a26f9-5b4e234c Brave Software (Brave Core Nightly Key) (We're reinventing the browser as a user-first platform for speed and privacy.) <support> public key gpg-pubkey-f661cdcb-63ab09ad Brave Linux Pre Release (Brave Linux Pre Release) <brave-linux-pre-release> public key gpg-pubkey-4218647e-61f7b089 Vivaldi Package Composer KEY08 <packager> public key gpg-pubkey-33eaab8e-63bd672b Vivaldi Package Composer KEY09 <packager> public key gpg-pubkey-c2d4e821-5bc51032 Brave Software <support> public key cd /usr/lib/python3.12/site-packages dnf update DNSSEC extension: Testing already imported keys for their validity. DNSSEC extension: GPG Key packager has been revoked and should be removed immediately DNSSEC extension: GPG Key support has been revoked and should be removed immediately DNSSEC extension: GPG Key fedora-39-primary has been revoked and should be removed immediately Last metadata expiration check: 0:01:49 ago on Tue 14 Nov 2023 12:33:14 PM EST. Dependencies resolved. Nothing to do. Complete! wget https://patch-diff.githubusercontent.com/raw/rpm-software-management/dnf/pull/2019.diff -O ~/patch1.txt patch -p1 < ~/patch1.txt patching file dnf/dnssec.py dnf update DNSSEC extension: Testing already imported keys for their validity. Last metadata expiration check: 0:01:49 ago on Tue 14 Nov 2023 12:33:14 PM EST. Dependencies resolved. Nothing to do. Complete!
> (Your test also reveals that the code does not support multiple keys in DNS for the same e-mail address.) This was never implemented. But there existed a draft https://github.com/rpm-software-management/dnf/pull/1733
(In reply to pgnd from comment #28) > rm -rf /var/cache/dnf/{vivaldi,brave}* > rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep > -iE "vivaldi|brave" > (empty) > > dnf clean all > dnf update > DNSSEC extension: Testing already imported keys for their validity. > ... > vivaldi > 3.2 kB/s | 833 B 00:00 > vivaldi > 65 kB/s | 3.1 kB 00:00 > Importing GPG key 0x4218647E: > Userid : "Vivaldi Package Composer KEY08 <packager>" > Fingerprint: DF44 CF0E 1930 9195 C106 9AFE 6299 3C72 4218 647E > From : https://repo.vivaldi.com/archive/linux_signing_key.pub > Is this ok [y/N]: y > vivaldi > 199 kB/s | 31 kB 00:00 > ... > > rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep > -iE "vivaldi|brave" > (empty) > That's strange. For me DNF imports a key only if a package signed with the key is going to be (re)installed. Maybe you have another DNF option set I don't have. > dnf reinstall vivaldi-stable brave-browser brave-keyring > ... > DNSSEC extension: Key for user packager has unknown status. > Importing GPG key 0x4218647E: > Userid : "Vivaldi Package Composer KEY08 <packager>" > Fingerprint: DF44 CF0E 1930 9195 C106 9AFE 6299 3C72 4218 647E > From : https://repo.vivaldi.com/archive/linux_signing_key.pub > NOT verified using DNS record. > Is this ok [y/N]:y > Key imported successfully > Public key for brave-browser-1.60.114-1.x86_64.rpm is not installed > Public key for brave-keyring-1.14-1.noarch.rpm is not installed > 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 > > rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep > -iE "vivaldi|brave" > gpg-pubkey-4218647e-61f7b089 Vivaldi Package Composer KEY08 > <packager> public key > This works for me the same as for you.
Honza, I can see you update dnf in Fedora once in a month. Can I apply the 3 upstream patches to Fedora ≥ 39 right now, or do you prefer waiting on a next upstream release?
(In reply to Petr Pisar from comment #32) > Honza, I can see you update dnf in Fedora once in a month. Can I apply the 3 > upstream patches to Fedora ≥ 39 right now, or do you prefer waiting on a > next upstream release? For me, the release cadence depends on the readiness of new features since the latest upstream release and their criticality. As I see it now, there don't appear to be many new features, and given the medium priority of this ticket, I am for doing the release in about two weeks from now. But I am perfectly fine with applying just the patches in downstream by yourself if you'd like to.
Thanks for the review the response. I will apply the fix in downstream.
FEDORA-2023-1018396a7d has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1018396a7d
test @ my copr dnf-4.18.1-2.fc39.noarch looks good thx! o/
FEDORA-2023-1018396a7d has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1018396a7d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1018396a7d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-1018396a7d has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.