All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry: http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signatu...
Few last minutes notes here: - there are still some gotchas which should be fixed. But enough code is already in production - you can play with it now. Relevant issues are linked in the blog post. - the DNF team is migrating their code to libdnf, I do not have any guarantee when this piece of code will be migrating - so we are far from enabling this by default.
Comments are welcomed.
On Fri, Feb 12, 2021 at 08:22:45PM +0100, Miroslav Suchý wrote:
Comments are welcomed.
You can use "host -t TYPE61" instead of "dig" to get less verbose output. "host -v -t TYPE61" will show a little more (like the flags) while still being less noisy than dig.
On Fri, Feb 12, 2021 at 02:47:47PM -0500, Matthew Miller wrote:
On Fri, Feb 12, 2021 at 08:22:45PM +0100, Miroslav Suchý wrote:
Comments are welcomed.
You can use "host -t TYPE61" instead of "dig" to get less verbose output. "host -v -t TYPE61" will show a little more (like the flags) while still being less noisy than dig.
Or just use resolvectl:
$ COLUMNS=80 resolvectl openpgp fedora-27@fedoraproject.org 2d81eb3c5ebd20d163ff111a2dbcdc7e3336825d7d2331a3ef543aa8._openpgpkey.fedoraproject.org IN OPENPGPKEY mQINBFiskqMBEADTbsoAXpDPk+FtcwBEPZQVe0YQYdOqavfQQVD/RYAcHnJW/K1bZhQusBj UIec9SfGi3uBNNmbziAvpd/ycMKyWHuWQLmBgbImrqnPbBPMXmxeNGnZjA1hjVDp0pzj2+g ZQhqYWSf6kQy9u9A1mSU63Kl/tfw7+hX7Tc3I8feGAFCHcFQgESxUib8Mw/OOGR3Am9fKdA +K1kJeQIiZvXMcNFx+3CfoavhFdicuoT2KbcSuzRm76duKNHlLaP6/IbZxNiDWh8SDVpFaF PlqR/R/+wibA6e9wMf6CZ4vfUY7NKYf4tYBs0EYdkn3j/KhJJxdb+M46Q/xwq9ovZo7XIhL rIUPuMw91X9cbvkU/a9kE1ffdpNmF1fDnUcEkuuEqOl+aMVsUBEbAQ86yrwpDfL4XT9vwnD IkggKZyvDTZ6q00XKg3GerKuZtQBl/YcHDXuBlB1fzpGl8a8hq/+GeT2sVxjlYwPXjrsKd1 NeP6ctQsR6gHuP3W5ohP4rArtM6ONN8rlTiodDLVGHBpUzIRdgr7RCL1AqB9vrdQ2MVZMas TcUnUvKo0H4mps+x05jGao0b0Z0TJc6wr6ybHH38NVG06VX5rJZlfZchGwkWzmYxai55/7l n1vJmk+kbdS7pK0jfmeVJ8A77XLCL36oJFCiCrYjV+ZGgvB+z08Jzwc7sgwARAQABtCxGZW RvcmEgMjcgKDI3KSA8ZmVkb3JhLTI3QGZlZG9yYXByb2plY3Qub3JnPokCOAQTAQIAIgUCW KySowIbDwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ9V50MPUoLuTcww/+LFPVEyVg uMeU/QABEsE5FEN7kcDReZtdwq7p/aKC29mzCxeHggitYOGlrINkJ26Aq6p+oW6w7JxBWJn KoTBYJDFzNIbp/6GbG4oKcEnWQZfTnRLTr5aukVdWBFevzC0huraobKz3joYRIX826VUzS/ A418zpnDVPtpo3x86V9f292rqi2tn9Q5cQC5Ck3/cjQDEwkN9gHz4j/c1oa6zBOcHbKkaZd WA2dIs6XOxCIHg78i6VQwMMs+vfm2vbV3ACCcOVnd3d6NxIQuDLEQwdtdB2zI8R74bjacos rcafK+F2DnkM7WrLSCiTKLJBMRDx+X2nOjT5pLuts4FC/XYRO23SMtPAMzQ852Z1lkjsaVD sjzNqCasUB0vDPHLQE8aj0zchNBSzuHoKpXNYTyJztekWL/QXkUsXu0x7N5WhBlZ+lni6Lt ZU51l7BJd1n+ZKnQ4gmjQ1ffVLbgzb9Z1MNje0s61FdKmUJQGULYqh32W4GV+RLvtI6AJV/ EmFCUEfRJ3eA8tJiyKe512wiim/WDhvzFuuPBup2Z3TufiaJQOysLlN5+HUQitTtcd7j8Zg psIAIZtSWOMxbIAJWbzn8gjfIj4ZDeo0ZZXH0VgDkXtpv1g8R2aRAz6ob5YYW5VnI2UEr53 x1Z7lmUhv/TUZn26IeU16jCJ80k7pJvQSF8Y= -- link: host0
-- Information acquired via protocol DNS in 851us. -- Data is authenticated: yes
Zbyszek
Miroslav Suchý wrote:
All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry: http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signatu...
More checking doesn't hurt, but mostly this looks like a different solution to a problem that Fedora already has a solution to. The changes to DNF aren't an answer to the question in your blog post:
But how to fetch the very first GPG key?
The first key that gets imported to RPM is included in the installation image and gets installed along with the rest of the system, but that's not the very first key. The very first OpenPGP key is the one you need to verify the installation image before you start the installation. (Okay, technically the same key is used for both purposes, but that's an irrelevant detail.)
If you install from a malicious installation image, then your Fedora system is already compromised before DNF has a chance to look up any key. On the other hand, once the image is verified you can trust its contents, including the keys that will later be used to verify downloaded packages. (Assuming of course that you can trust the computer you used to verify the image, and the USB memory you write it to. It's trust all the way down.)
Verifying the installation image isn't a thing that RPM and DNF can help you with. That may well need to happen on a non-RPM-based system. What would help is if GnuPG could fetch and verify the key automatically. (It would also help if we had detached OpenPGP signatures of the images so we could skip the sha256sum step.) According to the manual, GnuPG can look up keys in DNS in various ways, but it tries only Web Key Directory by default. I think therefore that the greatest advantage of publishing the keys in DNS is that it can help with verifying installation images, but it might be even better to publish them in a Web Key Directory.
Björn Persson
On Sat, Feb 13, 2021 at 12:15:14AM +0100, Björn Persson wrote:
The first key that gets imported to RPM is included in the installation image and gets installed along with the rest of the system, but that's not the very first key. The very first OpenPGP key is the one you need to verify the installation image before you start the installation. (Okay, technically the same key is used for both purposes, but that's an irrelevant detail.)
If you install from a malicious installation image, then your Fedora system is already compromised before DNF has a chance to look up any key. On the other hand, once the image is verified you can trust its contents, including the keys that will later be used to verify downloaded packages. (Assuming of course that you can trust the computer you used to verify the image, and the USB memory you write it to. It's trust all the way down.)
Verifying the installation image isn't a thing that RPM and DNF can help you with. That may well need to happen on a non-RPM-based system. What would help is if GnuPG could fetch and verify the key automatically. (It would also help if we had detached OpenPGP signatures of the images so we could skip the sha256sum step.) According to the manual, GnuPG can look up keys in DNS in various ways, but it tries only Web Key Directory by default. I think therefore that the greatest advantage of publishing the keys in DNS is that it can help with verifying installation images, but it might be even better to publish them in a Web Key Directory.
I'd not oppose making verification easier, but I think we really need to try and find a better solution than gpg. No offense to all the hard work thats gone into it, it's just... not something you can expect non geeks to bother with or figure out usually.
For windows and macos, we have fedora media writer. Of course they would then need to verify _that_
It's really not an easy problem. :(
kevin
Hi,
if you approach the question of where to anchor your trust from too broad perspective you end up with no other option but throwing your computer out of the window (joking, don't do that).
This system has other advantages as well: * it can automatically install keys for 3rd party repos and verify them using the DNSSEC trust anchor which is preinstalled on the system * it can help in case of revocation as there is currently no way to do that automatically * Except for some corner cases I expect all RPM repo providers to have a DNS domain which can be used to store the key, so there is no additional software required
The main disadvantage of the system is that it uses DNS and that is unfortunately very unreliable.
Martin Sehnoutka
On 2/13/21 12:15 AM, Björn Persson wrote:
Miroslav Suchý wrote:
All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry: http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signatu...
More checking doesn't hurt, but mostly this looks like a different solution to a problem that Fedora already has a solution to. The changes to DNF aren't an answer to the question in your blog post:
But how to fetch the very first GPG key?
The first key that gets imported to RPM is included in the installation image and gets installed along with the rest of the system, but that's not the very first key. The very first OpenPGP key is the one you need to verify the installation image before you start the installation. (Okay, technically the same key is used for both purposes, but that's an irrelevant detail.)
If you install from a malicious installation image, then your Fedora system is already compromised before DNF has a chance to look up any key. On the other hand, once the image is verified you can trust its contents, including the keys that will later be used to verify downloaded packages. (Assuming of course that you can trust the computer you used to verify the image, and the USB memory you write it to. It's trust all the way down.)
Verifying the installation image isn't a thing that RPM and DNF can help you with. That may well need to happen on a non-RPM-based system. What would help is if GnuPG could fetch and verify the key automatically. (It would also help if we had detached OpenPGP signatures of the images so we could skip the sha256sum step.) According to the manual, GnuPG can look up keys in DNS in various ways, but it tries only Web Key Directory by default. I think therefore that the greatest advantage of publishing the keys in DNS is that it can help with verifying installation images, but it might be even better to publish them in a Web Key Directory.
Björn Persson
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Martin Sehnoutka wrote:
This system has other advantages as well:
- it can automatically install keys for 3rd party repos and verify
them using the DNSSEC trust anchor which is preinstalled on the system
RPM Fusion is an example of such a third-party repo. To use packages from RPM Fusion you'll first manually download and install the rpmfusion-free-release package, which contains the repo files and keys.
Suppose a bad guy has somehow tricked you into downloading a malicious version of rpmfusion-free-release. The package is signed by brad.guy@malicious.example, and the key is published in the domain malicious.example. All the DNSsec signatures are in perfect order, so you can be quite sure that the key really does belong to brad.guy@malicious.example. Do you trust Brad? Should you install the package?
Obviously we want a package signed by an attacker to fail the verification. Section 3 of your thesis describes how the modified DNF uses DNSsec to verify that the key is valid for the stated email address, but I don't see anything about how it decides whether the email address is correct for the repository, or whether the person behind that email address is trusted. You state that the DNS server isn't necessarily in the same domain as the repository, so it's not as simple as comparing the domain names. Could you explain how the email address is validated?
Björn Persson
Dne 08. 03. 21 v 15:01 Björn Persson napsal(a):
Suppose a bad guy has somehow tricked you into downloading a malicious version of rpmfusion-free-release. The package is signed by brad.guy@malicious.example, and the key is published in the domain malicious.example. All the DNSsec signatures are in perfect order, so you can be quite sure that the key really does belong to brad.guy@malicious.example. Do you trust Brad? Should you install the package?
Let's compare it to a current situation. I deleted F34 and F35 GPG keys from my system.
When I tried to run (and I used distribution-gpg-key package for the test):
# dnf install http://ftp.halifax.rwth-aachen.de/fedora/linux/development/rawhide/Everythin...
Then DNF does not blink an eye and install this package even when the GPG keys is not known. (it is because of default setting of localpkg_gpgcheck).
BTW when I try: # rpm -i distribution-gpg-keys-1.51-1.fc35.noarch.rpm warning: distribution-gpg-keys-1.51-1.fc35.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY
I.e. the package have been installed. Though rpm emits a warning. But I doubt that average sysadmin would treat this warning seriously.
And if you download and install package containing .repo file where baseurl points to malicious repo and the package install malicious GPG key, then you are screwed anyway. In postscriptlet, or unit file, you can import the GPG key to rpmdb and do whatever you want.
It does not matter if you used DNS(SEC) verification or not. You simple should check the GPG key and you should not trust the key emmited by brad.guy@malicious.example.
Obviously we want a package signed by an attacker to fail the verification. Section 3 of your thesis describes how the modified DNF uses DNSsec to verify that the key is valid for the stated email address, but I don't see anything about how it decides whether the email address is correct for the repository, or whether the person behind that email address is trusted. You state that the DNS server isn't necessarily in the same domain as the repository, so it's not as simple as comparing the domain names. Could you explain how the email address is validated?
The domain for the repository above is ftp.halifax.rwth-aachen.de, but the GPG key for packages there use @fedoraproject.org. That's what an author meant.
Now, lets try something little different. I still do not have F34 and F35 GPG keys. I am on F33. And lets run:
# dnf install --releasever=34 distribution-gpg-keys ... Installed size: 434 k Is this ok [y/N]: y Downloading Packages: ... Importing GPG key 0x45719A39: Userid : "Fedora (34) fedora-34-primary@fedoraproject.org" Fingerprint: 8C5B A699 0BDB 26E1 9F2A 1A80 1161 AE69 4571 9A39 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 Is this ok [y/N]:
That is interesting. Let pretend that attacker changed something by MITM attack and tricked me to download his package. If he signed package using brad.guy@malicious.example email. Then DNF will tell me:
Importing GPG key 0x45719A39: Userid : "hahah brad.guy@malicious.example" Fingerprint: some thing bad and not matching From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64
The package is signed using brad.guy@malicious.example and if he has corresponding DNS entry and DNSSEC on malicious.example, then DNF tells me: Verified using DNS record with DNSSEC signature. I.e. that owner of malicious.example domain say that GPG key for brad.guy@malicious.example is correct. I would need to be dumb to allow import of brad.guy@malicious.example GPG key.
Attacker learned the lesson and he created new GPG pair and he use email address fedora-34-primary@fedoraproject.org. GPG will not stop you. And it is okay to have several GPG keys for one email (CentOS does that).
I run dnf again and DNF tells me: Importing GPG key 0x45719A39: Userid : "Fedora (34) fedora-34-primary@fedoraproject.org" Fingerprint: some thing not correct From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 Is this ok [y/N]:
The email match. The filename match. Fingerprint? That is long, there is no time. It is ok, proceed.... and voila, I am hacked.
Let's try that with gpgkey_dns_verification=1
Importing GPG key 0x45719A39: Userid : "Fedora (34) fedora-34-primary@fedoraproject.org" Fingerprint: some thing not correct From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 NOT verified using DNS record. Is this ok [y/N]:
That sounds fishy. I will try to check the fingerprint. But even if I proceed. Then every time DNF starts, it will check the DNS entries and I will get:
"GPG Key {} could not be verified, because DNSSEC signatures" " are bogus. Possible causes: wrong configuration of the DNS" " server, MITM attack".format(key.email)
This is getting long. What is the conclusion? GPG in DNS is not equivalent of **authorization**. It is still up to admin to approve the key. And it will not open your system. Not more than it is now. GPG in DNS is more equivalent of **authentication**. You will not need to compute fingerprint and manually compare it with fingerprint on website (or what you are using). When the email is foo@domain.com and have DNS(SEC) entry then you can be sure that the domain owner confirms the identity of that GPG keys. It is up to you whether you will trust the owner of that domain.
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
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. That is especially valid if user just changed --releasever, but repository file remains from trusted source.
Installing unsigned package provides no way to ensure it cames from trusted source. There is anything we can do about that, admin either knows what he does or can be fooled to anything.
I don't understand why old keys don't provide transition to new keys, while they are still valid. DNSSEC allows us to ensure they are still current and non-revoked. But still, when I use dnf install --releasever 35 <something>, it asks me for confirmation of new f35 key. But If I already trust f33 key, it might sign f35 key before obsoleted itself. It would provide me safe upgrade path to new release keys.
Is there reason why we consider new release keys as completely unrelated to previous keys? Is it technical decision or just lack of better implementation?
Regards, Petr
On 3/9/21 4:56 PM, Miroslav Suchý wrote:
Dne 08. 03. 21 v 15:01 Björn Persson napsal(a):
Suppose a bad guy has somehow tricked you into downloading a malicious version of rpmfusion-free-release. The package is signed by brad.guy@malicious.example, and the key is published in the domain malicious.example. All the DNSsec signatures are in perfect order, so you can be quite sure that the key really does belong to brad.guy@malicious.example. Do you trust Brad? Should you install the package?
Let's compare it to a current situation. I deleted F34 and F35 GPG keys from my system.
When I tried to run (and I used distribution-gpg-key package for the test):
# dnf install http://ftp.halifax.rwth-aachen.de/fedora/linux/development/rawhide/Everythin...
Then DNF does not blink an eye and install this package even when the GPG keys is not known. (it is because of default setting of localpkg_gpgcheck).
BTW when I try: # rpm -i distribution-gpg-keys-1.51-1.fc35.noarch.rpm warning: distribution-gpg-keys-1.51-1.fc35.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY
I.e. the package have been installed. Though rpm emits a warning. But I doubt that average sysadmin would treat this warning seriously.
And if you download and install package containing .repo file where baseurl points to malicious repo and the package install malicious GPG key, then you are screwed anyway. In postscriptlet, or unit file, you can import the GPG key to rpmdb and do whatever you want.
It does not matter if you used DNS(SEC) verification or not. You simple should check the GPG key and you should not trust the key emmited by brad.guy@malicious.example.
Obviously we want a package signed by an attacker to fail the verification. Section 3 of your thesis describes how the modified DNF uses DNSsec to verify that the key is valid for the stated email address, but I don't see anything about how it decides whether the email address is correct for the repository, or whether the person behind that email address is trusted. You state that the DNS server isn't necessarily in the same domain as the repository, so it's not as simple as comparing the domain names. Could you explain how the email address is validated?
The domain for the repository above is ftp.halifax.rwth-aachen.de, but the GPG key for packages there use @fedoraproject.org. That's what an author meant.
Now, lets try something little different. I still do not have F34 and F35 GPG keys. I am on F33. And lets run:
# dnf install --releasever=34 distribution-gpg-keys ... Installed size: 434 k Is this ok [y/N]: y Downloading Packages: ... Importing GPG key 0x45719A39: Userid : "Fedora (34) fedora-34-primary@fedoraproject.org" Fingerprint: 8C5B A699 0BDB 26E1 9F2A 1A80 1161 AE69 4571 9A39 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 Is this ok [y/N]:
That is interesting. Let pretend that attacker changed something by MITM attack and tricked me to download his package. If he signed package using brad.guy@malicious.example email. Then DNF will tell me:
Importing GPG key 0x45719A39: Userid : "hahah brad.guy@malicious.example" Fingerprint: some thing bad and not matching From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64
The package is signed using brad.guy@malicious.example and if he has corresponding DNS entry and DNSSEC on malicious.example, then DNF tells me: Verified using DNS record with DNSSEC signature. I.e. that owner of malicious.example domain say that GPG key for brad.guy@malicious.example is correct. I would need to be dumb to allow import of brad.guy@malicious.example GPG key.
Attacker learned the lesson and he created new GPG pair and he use email address fedora-34-primary@fedoraproject.org. GPG will not stop you. And it is okay to have several GPG keys for one email (CentOS does that).
I run dnf again and DNF tells me: Importing GPG key 0x45719A39: Userid : "Fedora (34) fedora-34-primary@fedoraproject.org" Fingerprint: some thing not correct From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 Is this ok [y/N]:
The email match. The filename match. Fingerprint? That is long, there is no time. It is ok, proceed.... and voila, I am hacked.
Let's try that with gpgkey_dns_verification=1
Importing GPG key 0x45719A39: Userid : "Fedora (34) fedora-34-primary@fedoraproject.org" Fingerprint: some thing not correct From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-x86_64 NOT verified using DNS record. Is this ok [y/N]:
That sounds fishy. I will try to check the fingerprint. But even if I proceed. Then every time DNF starts, it will check the DNS entries and I will get:
"GPG Key {} could not be verified, because DNSSEC signatures" " are bogus. Possible causes: wrong configuration of the DNS" " server, MITM attack".format(key.email)
This is getting long. What is the conclusion? GPG in DNS is not equivalent of **authorization**. It is still up to admin to approve the key. And it will not open your system. Not more than it is now. GPG in DNS is more equivalent of **authentication**. You will not need to compute fingerprint and manually compare it with fingerprint on website (or what you are using). When the email is foo@domain.com and have DNS(SEC) entry then you can be sure that the domain owner confirms the identity of that GPG keys. It is up to you whether you will trust the owner of that domain.
Dne 10. 03. 21 v 13:32 Petr Menšík napsal(a):
Is there reason why we consider new release keys as completely unrelated to previous keys? Is it technical decision or just lack of better implementation?
No one done this yet. Feel free to take it. I will love to have this.
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@fedoraproject.org
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
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.
Dne 10. 03. 21 v 17:43 Colin Walters napsal(a):
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>
Would you, as sysadmin, notice if the fingerprint changed (because of attacker)? I definitelly not.
That gpgkeyid=issuer@email.com gpgkey_dns_verification=1 is IMO better approach.
On Wed, Mar 10, 2021, at 1:06 PM, Miroslav Suchý wrote:
Dne 10. 03. 21 v 17:43 Colin Walters napsal(a):
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>Would you, as sysadmin, notice if the fingerprint changed (because of attacker)? I definitelly not.
That gpgkeyid=issuer@email.com gpgkey_dns_verification=1 is IMO better approach.
With this model, the fingerprint changing is a hard failure.
Now if you're scoping in key rotation - that is indeed a hard problem. Does COPR rotate keys today at all? I think it's fair to say that key rotation is the most broken-by-design thing about GPG. It's not clear to me that DNS is the right answer though.
We're having a parallel discussion about this in https://github.com/ostreedev/ostree/pull/2260
Dne 10. 03. 21 v 19:28 Colin Walters napsal(a):
With this model, the fingerprint changing is a hard failure.
Yes. But the question is whether you can easily find that you have been attacked or you are under attack. Yes, fingerprint is better than comparing whole key, but the UX still sucks.
Does COPR rotate keys today at all?
Nope. Copr does not rotate keys.
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@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!
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
Dne 10. 03. 21 v 20:43 Petr Menšík napsal(a):
If we finally fixed periodic gpg key breakage on new release branching, it should have been obtained by trusted way.
F36 gpg key has been already released. I thin that this summer we will have correct gpg keys all the time and branching will be flawless. Finger crossed.
Dne 12. 02. 21 v 20:22 Miroslav Suchý napsal(a):
All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry: http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signatu...
Few last minutes notes here: - there are still some gotchas which should be fixed. But enough code is already in production - you can play with it now. Relevant issues are linked in the blog post. - the DNF team is migrating their code to libdnf, I do not have any guarantee when this piece of code will be migrating - so we are far from enabling this by default.
Comments are welcomed.
Does somebody knows where is the source for: https://getfedora.org/security/ ? I want to submit PR with information that these keys are in DNS as well, but I have no idea where to go.
On Sat, Feb 13, 2021 at 05:57:07PM +0100, Miroslav Suchý wrote:
Does somebody knows where is the source for: https://getfedora.org/security/ ? I want to submit PR with information that these keys are in DNS as well, but I have no idea where to go.
https://pagure.io/fedora-web/websites/blob/master/f/sites/getfedora.org/site...
Docs for the framework: https://docs.fedoraproject.org/en-US/websites/
Hi,
as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used, when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61 might be used as fallback for older releases
On 2/12/21 8:22 PM, Miroslav Suchý wrote:
All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry: http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signatu...
Few last minutes notes here: - there are still some gotchas which should be fixed. But enough code is already in production - you can play with it now. Relevant issues are linked in the blog post. - the DNF team is migrating their code to libdnf, I do not have any guarantee when this piece of code will be migrating - so we are far from enabling this by default.
Comments are welcomed.
Dne 22. 02. 21 v 21:11 Petr Menšík napsal(a):
as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used, when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61 might be used as fallback for older releases
Because I did not knew that -t OPENPGPKEY can be used. :) No other reason.
On 2/23/21 9:30 AM, Miroslav Suchý wrote:
Dne 22. 02. 21 v 21:11 Petr Menšík napsal(a):
as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used, when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61 might be used as fallback for older releases
Because I did not knew that -t OPENPGPKEY can be used. :) No other reason.
Every type it can display on output is accepted also in input. Only types printed as TYPEX, where it does not know them, have to be used with numbered types.
It can be emulated by dig +unknownformat for any known type too.
On Friday, 12 February 2021 at 20:22, Miroslav Suchý wrote:
All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry: http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signatu...
Few last minutes notes here:
- there are still some gotchas which should be fixed. But enough code is
already in production - you can play with it now. Relevant issues are linked in the blog post.
- the DNF team is migrating their code to libdnf, I do not have any
guarantee when this piece of code will be migrating - so we are far from enabling this by default.
Comments are welcomed.
systemd-resolved breaks this in F33: https://bugzilla.redhat.com/show_bug.cgi?id=1823480
Regards, Dominik
devel@lists.stg.fedoraproject.org
-
Björn Persson -
Colin Walters -
Dominik 'Rathann' Mierzejewski -
Jan Pokorný -
Kevin Fenzi -
Martin Sehnoutka -
Matthew Miller -
Miroslav Suchý -
Petr Menšík -
Zbigniew Jędrzejewski-Szmek