On Thu, Dec 05, 2024 at 08:53:05AM +0100, Jan Kolarik wrote: > 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. OK. > 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 think the issue is not specific to Fedora and would apply to all distros using DNF/rpm. This is because of some generic properties: 1. rpm checks keys also when uinstalling packages and will fail to operate if the system has an rpm installed without a valid key (*). 2. Keys are rotated between major versions of the system and users who upgrade distro versions end up with a bunch of keys. 3. Upgrades are common and supported, but downgrades are not supported and would often not work (also because of data format changes), so the old keys are never used again. Locking down of old keys prevents malicious or accidental installation of old unsupported packages. This also applies to systems where unprivileged users are allowed to install valid distro packages. As to the implementation: the distro has a historical list of all keys used to sign its packages. For any given release we know which keys are "old". In some fixed location, distribute a file that lists the hashes of "old keys" (old relative to the current distro release). In case of Fedora this could be distributed by fedora-release package. Whenever the user does an upgrade that adds _new_ keys, look at the list generated by 'rpmkey --list' and for each key also on the list of "old keys" query for removal. Zbyszek (*) This has come up before. Previously, I argued that this is not useful behaviour and that rpm should not check keys _after_ installation. The current behaviour seems to be justified by the implementation and not of concious design, but it is how it is. As an alternative approach, if we changed rpm so that 1. is not true, we could just remove old distro keys immediately during upgrade. This would be much simpler. -- _______________________________________________ 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
