#2881 Change: RPM Sequoia
Closed: Accepted 2 years ago by zbyszek. Opened 2 years ago by bcotton.

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.

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...


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

2 years ago

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

2 years ago

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.

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
 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).

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    
# 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
# 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 :


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.