On 3/10/21 5:43 PM, Colin Walters wrote: > > > 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@xxxxxxxxxxxxxxxxx > > 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! Agreed. System repositories should have been obtained via GPG signed packages. If we finally fixed periodic gpg key breakage on new release branching, it should have been obtained by trusted way. There should be no need to trust a new release key again manually. > > 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> > ``` How do I check what the correct fingerprint is on my system? How do I check it has not changed? Gpg fingerprint is related only to the single key. It does not allow safe roll of keys. If the key has to change, how can it *automatically* obtain the new fingerprint? DNSSEC and email allows the generation of a new key with the same email, which has trusted chain and can be just validated. New key would be imported if the old is invalid. How would you validate gpgkeyfingerprint? It would have to know authoritative URL to fetch current fingerprint (or the key itself) and compare it to the internal key. Does such url exist? Is it documented somewhere? Fingerprint helps only when installing a new repo. It does not contain signature of repo file, the only way is to trust ALL TLS authorities when fetching it. It would not be possible to supply trusted repo files on mirrors. If both repo and its key(s) are fetched from the same source, verification of fingerprint written in the repo file does not bring any more security IMHO. > > Having the full fingerprint supports fetching the key from anywhere too. Unless the fingerprint can be validated somehow, it creates just a false sense of security. > And the fingerprint+key is fetched via TLS, effectively a trust-on-first-use style model. This exactly is a problem. You should not be asked to trust it on the first use, if there exists already trusted key chain able to validate it. I guess most people just hit Y once asked to trust a new key, because it is convenient. But unsafe. Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
