On 12/5/24 10:42 AM, Zbigniew Jędrzejewski-Szmek wrote:
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 (*).
"fail to operate" is a rather wild exaggeration.
Rpm does not currently require any keys to be present, and there's not a
single visible consequence if you remove all your keys.
The issue with rpm-sequoia early days, which probably what you're
referring to here, was that all of a sudden various old keys no longer
were either valid at all, or expired, and so the signature checks were
actually failing. Rpm's actual behavior in that situation is not
particularly helpful, but it doesn't mean the idea itself is bad:
The feature is supposed to protect you against rpmdb tampering (think:
modify headers to hide naughty script/executable etc), it just falls of
its target due to various other things, such as unsigned packages being
okay.
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.
FWIW, we're working to have a rpmkeys --rebuild mode in rpm 6.0, which
will purge no longer valid keys as a part of its operation.
We could also have a mode to look for unused keys I suppose.
- Panu -
--
_______________________________________________
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
