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. Thanks, Jan On Wed, Dec 4, 2024 at 2:59 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> 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# > python...@copr.fedorahosted.org>) > cfc659b9-5b6eac67: gpg(Fedora (30) <fedora-30-prim...@fedoraproject.org>) > 3c3359c4-5c6ae44d: gpg(Fedora (31) <fedora-31-prim...@fedoraproject.org>) > 12c944d0-5d5156ab: Fedora (32) <fedora-32-prim...@fedoraproject.org> > public key > fd189222-55ffebf5: rpmsoftwaremanagement_dnf-nightly (None) > <rpmsoftwaremanagement#dnf-nigh...@copr.fedorahosted.org> public key > 429476b4-5a886537: gpg(Fedora 29 (29) <fedora...@fedoraproject.org>) > 9570ff31-5e3006fb: Fedora (33) <fedora-33-prim...@fedoraproject.org> > public key > 45719a39-5f2c0192: Fedora (34) <fedora-34-prim...@fedoraproject.org> > public key > 9867c58f-601c49ca: Fedora (35) <fedora-35-prim...@fedoraproject.org> > public key > bbdb9e20-60d98a7d: jmracek_weak_excludes (None) <jmracek# > weak_exclu...@copr.fedorahosted.org> public key > 38ab71f4-60242b08: Fedora (36) <fedora-36-prim...@fedoraproject.org> > public key > 2d9de8df-61378de3: @fedora-llvm-team_llvm-snapshots (None) > <@fedora-llvm-team#llvm-snapsh...@copr.fedorahosted.org> public key > 5323552a-6112bcdc: Fedora (37) <fedora-37-prim...@fedoraproject.org> > public key > 2d20b9c6-61555dd9: @python_python3.11 (None) <@python# > python3...@copr.fedorahosted.org> public key > eb10b464-6202d9c6: Fedora (38) <fedora-38-prim...@fedoraproject.org> > public key > fe562d49-5fca4469: rpmsoftwaremanagement_dnf5-unstable (None) > <rpmsoftwaremanagement#dnf5-unsta...@copr.fedorahosted.org> public key > 18b8e74c-62f2920f: Fedora (39) <fedora-39-prim...@fedoraproject.org> > public key > a15b79cc-63d04c2c: Fedora (40) <fedora-40-prim...@fedoraproject.org> > public key > e99d6ad1-64d2612c: Fedora (41) <fedora-41-prim...@fedoraproject.org> > public key > bb87e215-65428be0: zbyszek_nixos (None) <zbyszek# > ni...@copr.fedorahosted.org> public key > bb41cc10-66162ab1: zbyszek_merged-sbin (None) <zbyszek# > merged-s...@copr.fedorahosted.org> public key > 105ef944-65ca83d1: Fedora (42) <fedora-42-prim...@fedoraproject.org> > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
