On 3/10/21 1:32 PM, 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
This way dnf could map DNSSEC validated email to repository. It would be
user-verifiable, when he or she would add a new repository downloaded
from any site.
Excuse me if I am overthinking this, but "from any site" is that detail
wherein the proverbial devil is, I think.
I'd say you would want DNF to a priori realize that the domain part from
said "gpgkeyid=" indeed (partially) matches the domain you obtained this
very repo file from (prior to redirections[*]) be it either in the form
of "dnf install <internet-URL>.rpm" or hypothetical "--repofromrepopath"
counterpart of "--repofrompath" command (since baseurl= can generally
differ from where you obtain the repo from, but the same logic could
be applied when that's not the case).
In turn, that would restrict the location from where you can obtain
the repo file smoothly without alerts to only the domain(s) stricly
bound to the domain used in the address within gpgkeyid= (creating
thus a concept of authoritative repo file source). That would
apply on the surfacing URL only[*].
Otherwise, I think someone could be tricked to start from installing
https://rpmfusion-mirror.seams-leg.it/rpmfusion-free-release.noarch.rpm
and crafted gpgkeyid= in the installed repo would not exactly help.
Of course, applies only to cases of entirely foreign by then
repositories, like RPM Fusion (use case: visit its web [DNS
must have been trusted already], follow the instructions here,
be spared from a fraudulent mirror right from the start).
For Fedora (Linux) incremental versions, there should really be
some kind of a seamless "rolling trust" mechanism as discussed
in other part of the above message.
[*] feels like a compromise of redirect chain would still be captured
with the whole mechanism, but I might have missed something/a lot
--
Jan (poki)
_______________________________________________
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
