Change RPM to use Sequoia based OpenPGP parser instead of it's own, flawed and limited implementation.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
As someone that has actually hacked on RPM's signature handling, I'm a firm +1 in favor of this.
+1 as well.
Note that I might be slightly biased, because I am directly responsible for the Sequoia PGP, Thunderbird Sequoia PGP plugin, and rpm-sequoia packages in Fedora.
I have worked with the Sequoia project developers for a while, and am confident that they can resolve most of the "minor problems" with the current approach (i.e. support for an OpenSSL backend, and Fedora crypto policy support), given time.
I posted a question about ExclusiveArch: %{rust_arches} on the devel list, but regardless of the answer, I'm +1.
ExclusiveArch: %{rust_arches}
We will need to figure out what to do when Rust is broken or unavailable for an architecture. But, I guess we need to go with this. We don't have any better options...
+1
After reading the change description, I was in favor of this change, but I wanted to wait and see what I might learn from the discussion. I still agree that this is the sensible way forward.
Hmm, I see two dowsides: - lack of support for SHA1 - the nettle dependency
The latter is a problem because it reverses some of the progress we have done on minimizing the number of crypto libraries used in the base stack. There were various small installations which could do with openssl only. But the merge request to add support for openssl in sequoia seems fairly advanced, and it's not such a big issue. I hope we can switch back to openssl in the future, possibly even before F38.
The former is was extensively discussed already. I think it'd be nice to a have better story for backwards-compat here, but I think the advantages of the switch outweigh this.
I thought the change quite explicitly states the plan is to swap back to openssl when it becomes available. As Simo Sorce from the crypto team notes, nettle is so small (790KB vs 6.4MB of openssl) that this is not much of an issue, especially as a temporary arrangement.
There's also work underway to have rpm-sequoia honor system crypto policy which will handle the backwards compat matter: https://github.com/rpm-software-management/rpm-sequoia/issues/14
Let me know if the above need clarifying in the proposal.
After a week, the vote is
APPROVED (+8,0,-0)
Metadata Update from @bcotton: - Issue tagged with: pending announcement
Announced.
Metadata Update from @zbyszek: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
It appears this change was approved with an empty release notes section, why is that? It lists there being possible user changes, and in fact based on my experiences (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EAWVXA5IM3GXEF57SCLD644JU5OU26UR/), this change can have visible user consequences. Shouldn't there be something in the release notes describing this change and its potential impact on 3rd-party repositories/RPMs?
Release notes rarely get filled out immediately, but I agree that documentation needs to be made for this change as we approach GA.
Are there any documented steps on debugging why a package installation failure due to :drumroll: Error: GPG check FAILED is happening? Surely there is something wrong with the key used to sign the RPM.
Error: GPG check FAILED
But which key?
And what exactly is wrong with it? How does one figure this out?
Ultimately Error: GPG check FAILED is less than helpful. :disappointed:
Clearly this won't happen for an RPM in F38, where this change landed, but for example:
# dnf --installroot /var/lib/mock/opensuse-leap-15.4-x86_64-bootstrap/root/ --releasever=15.4 install system-user-root openSUSE Leap 15.4 - x86_64 - OSS 18 kB/s | 10 kB 00:00 openSUSE Leap 15.4 - x86_64 - OSS - Updates 6.3 kB/s | 3.1 kB 00:00 openSUSE Leap 15.4 - x86_64 - Updates from SUSE Linux Enterprise 6.5 kB/s | 3.0 kB 00:00 openSUSE Leap 15.4 - x86_64 - Updates from Backports for SUSE Linux Enterprise 6.4 kB/s | 3.1 kB 00:00 Dependencies resolved. ============================================================================================================================================================================================ Package Architecture Version Repository Size ============================================================================================================================================================================================ Installing: system-user-root noarch 20190513-3.3.1 opensuse-leap-oss 9.0 k Transaction Summary ============================================================================================================================================================================================ Install 1 Package Total size: 9.0 k Installed size: 186 Downloading Packages: [SKIPPED] system-user-root-20190513-3.3.1.noarch.rpm: Already downloaded Problem opening package system-user-root-20190513-3.3.1.noarch.rpm Error: GPG check FAILED
which (for clarity) is trying to use dnf on F38 to install a Leap 15.4 package in a Leap 15.4 chroot (created by mock in case that was not clear).
dnf
mock
Most likely there is a problem with a SUSE key here, but per my original question(s): 1. which key 2. what is wrong with it?
so that I can at least go file a meaningful bug report with either SUSE or https://github.com/xsuchy/distribution-gpg-keys.
Got a bit further:
# dnf --installroot /var/lib/mock/opensuse-leap-15.4-x86_64-bootstrap/root/ --releasever=15.4 download system-user-root openSUSE Leap 15.4 - x86_64 - OSS 14 kB/s | 10 kB 00:00 openSUSE Leap 15.4 - x86_64 - OSS - Updates 6.3 kB/s | 3.1 kB 00:00 openSUSE Leap 15.4 - x86_64 - Updates from SUSE Linux Enterprise 6.4 kB/s | 3.0 kB 00:00 openSUSE Leap 15.4 - x86_64 - Updates from Backports for SUSE Linux Enterprise 6.4 kB/s | 3.1 kB 00:00 system-user-root-20190513-3.3.1.noarch.rpm # rpm --root /var/lib/mock/opensuse-leap-15.4-x86_64-bootstrap/root/ -qip system-user-root-20190513-3.3.1.noarch.rpm error: system-user-root-20190513-3.3.1.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 39db7c82: BAD # rpm --root /var/lib/mock/opensuse-leap-15.4-x86_64-bootstrap/root/ -qa | grep gpg-pubkey | grep 39db7c82 gpg-pubkey-39db7c82-510a966b # rpm --root /var/lib/mock/opensuse-leap-15.4-x86_64-bootstrap/root/ -qi gpg-pubkey-39db7c82-510a966b Name : gpg-pubkey Version : 39db7c82 Release : 510a966b Architecture: (none) Install Date: Mon May 1 17:18:02 2023 Group : Public Keys Size : 0 License : pubkey Signature : (none) Source RPM : (none) Build Date : Thu Jan 31 16:06:03 2013 Build Host : localhost Packager : SuSE Package Signing Key <build@suse.de> Summary : SuSE Package Signing Key <build@suse.de> public key Description : -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFEKlmsBCADbpZZbbSC5Zi+HxCR/ynYsVxU5JNNiSSZabN5GMgc9Z0hxeXxp YWvFoE/4n0+IXIsp83iKvxf06Eu8je/DXp0lMqDZu7WiT3XXAlkOPSNV4akHTDoY 91SJaZCpgUJ7K1QXOPABNbREsAMN1a7rxBowjNjBUyiTJ2YuvQRLtGdK1kExsVma hieh/QxpoDyYd5w/aky3z23erCoEd+OPfAqEHd5tQIa6LOosa63BSCEl3milJ7J9 vDmoGPAoS6ui7S2R5X4/+PLN8Mm2kOBrFjhmL93LX0mrGCMxsNsKgP6zabYKQEb8 L028SXvl7EGoA+Vw5Vd3wIGbM73PfbgNrXjfABEBAAG0KFN1U0UgUGFja2FnZSBT aWduaW5nIEtleSA8YnVpbGRAc3VzZS5kZT6JATwEEwECACYCGwMGCwkIBwMCBBUC CAMEFgIDAQIeAQIXgAUCX2himwUJFeKaMAAKCRBwr56BOdt8glQcCACXQAkHKf0y 7EPlayuX/EHc8sro4IAJDZqQFiPaJh8F+5HWD36+iw3D/HlOlzbd2y9oVqtbVDZV amOJ0KV+l2oxPbMVg32plYGXLlXh1Gwp7/lLWieceXVzf3AbleejgXfafUyiCuvj VaQyPNcGlEXIjiwi3qulw0+2rYAiUAf6KEq4wM9a/KLTLMhvxi2NigC+MiIbZtmt HlpFhMkp+Bdpdcqtz6cAucE3dSpVQcvkfNLOkZgrtkZfzkNBPaWnyZLtWdSrQah2 vdIQX+RvMYVAQP4x+aL44ALlhnyeUST0wIX4AH82ifSnpvz/rEb1kpERj3XhwW+N NPBstHtGpA+l =cJ/8 -----END PGP PUBLIC KEY BLOCK-----
but still not seeing what is wrong with the key. So still in the dark.
But even the above is a lot of palaver just to find out what is wrong with a key (as incomplete as it is still). It would be sooooo much more helpful if rpm and dnf even would say more about what is wrong with a given key.
FESCo tickets are not a support forum. Please take this to https://discussion.fedoraproject.org/ or the users@fedoraproject.org list.
Well, except that this "feature" was added without complete functionality or documentation on how to debug failures.
But I will go file a ticket elsewhere.
Login to comment on this ticket.