Open DemiMarie opened 3 years ago
See also https://github.com/rpm-software-management/libdnf/issues/43 - we rely today on the semantic of importing keys from /etc/pki/rpm-gpg/
and not having them in the rpmdb ahead of time in all cases.
See also rpm-software-management/libdnf#43 - we rely today on the semantic of importing keys from
/etc/pki/rpm-gpg/
and not having them in the rpmdb ahead of time in all cases.
My assumption was that higher-level tools will respond to this by importing the key and retrying.
Yes, we're considering moving from gnupg2/gpgme to librpm already. It's not going to change in the current (dnf4) code base.
Yes, we're considering moving from gnupg2/gpgme to librpm already. It's not going to change in the current (dnf4) code base.
What is the timeline for dnf5? I ask because this is blocking critical security improvements, specifically metadata signing enforcement.
There is no exact release date, but I hope it's going to be available by the end of the calendar year.
I can provide a nice C++ wrapper API that validates signatures in various ways before passing them to librpm.
This will allow using the RPM keyring and fix many bugs.