On Wed, Mar 10, 2021, at 7:32 AM, Petr Menšík wrote:
I think Björn's point is valid note. Because DNSSEC is used to
verify
email of used key, but fedora.repo does not contain any hint about how
email in GPG key should look like. Also does not contain fingerprint of
such key. It would be nice to include email of included GPG key in repo
file itself. If actual email in GPG did not match, dnf would refuse such
key unless explicitly requested by user.
What if we added to repos:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
gpgkeyid=mailto:fedora-$releasever-primary@fedoraproject.org
See also
https://github.com/rpm-software-management/libdnf/issues/43 - a massive
difference today between /usr/bin/dnf and libdnf-based things (like rpm-ostree and
PackageKit) is that libdnf auto-imports keys without prompting.
For ostree we added support for doing the same, so that's how our rpm-ostree based
systems work by default (same set of GPG keys).
There should really be an entirely separate flow for system repos versus 3rd party.
It's just plain dumb for us to prompt the user "Do you trust this Fedora GPG
key" if we already put the RPMs on disk!
This is still today worked around in e.g.
https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_110
for traditional yum/dnf based systems.
For 3rd party repositories like COPR, as I noted in that issue I think the best is to
bootstrap trust over TLS - e.g. we have
```
gpgkeyfingerprint=<sha256>
```
Having the full fingerprint supports fetching the key from anywhere too.
And the fingerprint+key is fetched via TLS, effectively a trust-on-first-use style model.