Hi Zbyszek,
Thank you for your interest in this proposal!
I'd like to see behaviour where keys for EOL releases are removed as
soon as possible. I.e. if I have upgraded to F42, but still have a
package from F39, then keep the key for F39 so that rpm doesn't
faceplant. But as soon as I remove the last package signed with that
key, remove the key automatically. Does the proposed plugin implement
something like this, and if not, would it be possible?
The primary use case this proposal aims to address is outlined in the upstream ticket: https://github.com/rpm-software-management/dnf5/issues/1192. Specifically, it focuses on scenarios where a repository key has expired and been prolonged. In such cases, the system should remove the expired key and fetch the updated one to ensure continued ability to install RPM packages from the repository already configured on the system.
I understand your point regarding Fedora keys, but that seems slightly off-topic from the current proposal's direction. Moreover, I currently don't see a generic, non-Fedora-specific way to handle such situations—specifically, determining if a key was superseded by another from a subsequent release and whether the old key is no longer needed.
That said, if you have ideas on how to address this, I’d be happy to discuss them further.
I understand your point regarding Fedora keys, but that seems slightly off-topic from the current proposal's direction. Moreover, I currently don't see a generic, non-Fedora-specific way to handle such situations—specifically, determining if a key was superseded by another from a subsequent release and whether the old key is no longer needed.
That said, if you have ideas on how to address this, I’d be happy to discuss them further.
Thanks,
Jan
On Wed, Dec 4, 2024 at 2:59 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
On Tue, Dec 03, 2024 at 05:18:12PM +0000, Aoife Moloney via devel-announce wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/Dnf5ExpiredPGPKeys
> The proposed solution is a new LIBDNF5 plugin. This plugin will act as
> a hook, checking for invalid repository PGP keys on the system before
> executing a DNF transaction.
>
> * '''Interactive mode''': The plugin will prompt the user to confirm
> the removal of each invalid key.
> * '''Non-interactive mode''' (e.g., with `-y` or `--assumeno`): The
> plugin will proceed automatically based on the specified user action,
> either removing the keys or retaining them.
This is an improvement over the current state, but (based on the
description here and a brief look at the discussion in the ticket),
it seems like valid-but-obsolete keys will not be removed. I think
that they definitely should, as soon as the last package using them
is removed.
On one of my systems:
$ rpmkeys --list
9507687b-5c7935d9: gpg(@python_python3.8 (None) <@python#python3.8@xxxxxxxxxxxxxxxxxxxxx>)
cfc659b9-5b6eac67: gpg(Fedora (30) <fedora-30-primary@xxxxxxxxxxxxxxxxx>)
3c3359c4-5c6ae44d: gpg(Fedora (31) <fedora-31-primary@xxxxxxxxxxxxxxxxx>)
12c944d0-5d5156ab: Fedora (32) <fedora-32-primary@xxxxxxxxxxxxxxxxx> public key
fd189222-55ffebf5: rpmsoftwaremanagement_dnf-nightly (None) <rpmsoftwaremanagement#dnf-nightly@xxxxxxxxxxxxxxxxxxxxx> public key
429476b4-5a886537: gpg(Fedora 29 (29) <fedora-29@xxxxxxxxxxxxxxxxx>)
9570ff31-5e3006fb: Fedora (33) <fedora-33-primary@xxxxxxxxxxxxxxxxx> public key
45719a39-5f2c0192: Fedora (34) <fedora-34-primary@xxxxxxxxxxxxxxxxx> public key
9867c58f-601c49ca: Fedora (35) <fedora-35-primary@xxxxxxxxxxxxxxxxx> public key
bbdb9e20-60d98a7d: jmracek_weak_excludes (None) <jmracek#weak_excludes@xxxxxxxxxxxxxxxxxxxxx> public key
38ab71f4-60242b08: Fedora (36) <fedora-36-primary@xxxxxxxxxxxxxxxxx> public key
2d9de8df-61378de3: @fedora-llvm-team_llvm-snapshots (None) <@fedora-llvm-team#llvm-snapshots@xxxxxxxxxxxxxxxxxxxxx> public key
5323552a-6112bcdc: Fedora (37) <fedora-37-primary@xxxxxxxxxxxxxxxxx> public key
2d20b9c6-61555dd9: @python_python3.11 (None) <@python#python3.11@xxxxxxxxxxxxxxxxxxxxx> public key
eb10b464-6202d9c6: Fedora (38) <fedora-38-primary@xxxxxxxxxxxxxxxxx> public key
fe562d49-5fca4469: rpmsoftwaremanagement_dnf5-unstable (None) <rpmsoftwaremanagement#dnf5-unstable@xxxxxxxxxxxxxxxxxxxxx> public key
18b8e74c-62f2920f: Fedora (39) <fedora-39-primary@xxxxxxxxxxxxxxxxx> public key
a15b79cc-63d04c2c: Fedora (40) <fedora-40-primary@xxxxxxxxxxxxxxxxx> public key
e99d6ad1-64d2612c: Fedora (41) <fedora-41-primary@xxxxxxxxxxxxxxxxx> public key
bb87e215-65428be0: zbyszek_nixos (None) <zbyszek#nixos@xxxxxxxxxxxxxxxxxxxxx> public key
bb41cc10-66162ab1: zbyszek_merged-sbin (None) <zbyszek#merged-sbin@xxxxxxxxxxxxxxxxxxxxx> public key
105ef944-65ca83d1: Fedora (42) <fedora-42-primary@xxxxxxxxxxxxxxxxx> public key
I'd like to see behaviour where keys for EOL releases are removed as
soon as possible. I.e. if I have upgraded to F42, but still have a
package from F39, then keep the key for F39 so that rpm doesn't
faceplant. But as soon as I remove the last package signed with that
key, remove the key automatically. Does the proposed plugin implement
something like this, and if not, would it be possible?
> Note that not all keys have a defined end of validity date.
Yeah. And they really shouldn't, because the packages that were once
signed remain valid with no defined EOL.
Do our package signing keys have end date?
$ rpm -q --qf "%{DESCRIPTION}" gpg-pubkey-18b8e74c-62f2920f | gpg --show-keys --with-colon | cut -d':' -f7
gpg: Warning: using insecure memory!
Zbyszek
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
