From a security point of view, I think it's a bad idea to cache copies of OpenPGP keys. It's up to the originator to say how to find his keys and you don't want to introduce a mechanism where your cache could be out of date or compromised relative to the source. For example: grep -l 'SRC_URI="https://dev.gentoo.org/~sam/distfiles/' /usr/portage/sec-keys/*/*d openpgp-keys-aacid/openpgp-keys-aacid-20220603.ebuild openpgp-keys-bradking/openpgp-keys-bradking-20220407.ebuild openpgp-keys-danielveillard/openpgp-keys-danielveillard-20210514.ebuild openpgp-keys-file/openpgp-keys-file-20220611.ebuild openpgp-keys-joelrosdahl/openpgp-keys-joelrosdahl-20220409.ebuild openpgp-keys-kamildudka/openpgp-keys-kamildudka-20220525.ebuild openpgp-keys-karelzak/openpgp-keys-karelzak-20220331.ebuild openpgp-keys-libidn/openpgp-keys-libidn-20220621.ebuild openpgp-keys-midipix/openpgp-keys-midipix-20210426.ebuild openpgp-keys-nettle/openpgp-keys-nettle-20220603.ebuild openpgp-keys-teemutoivola/openpgp-keys-teemutoivola-20210426.ebuild What's the rationale for this? Who is ~sam? I never asked him to cache GPG keys for me. Why should I trust him to cache the keys that I will be using to verify my downloads from a mirror? Especially when the keys have easy to retrieve canonical sources like : - https://savannah.gnu.org/project/release-gpgkeys.php - https://keyserver.ubuntu.com/pks/lookup - https://pgp.surfnet.nl/pks/lookup Even if the key is embedded in an HTML page I think it would be more transparent to pull down the key with FETCHCOMMAND and pipe it through a simple sed script to keep the key uncached. I think verify-sig is a great new feature of Gentoo as an added layer of defence-in-depth, and really appreciate all of the work it takes to do this. It's not just a "developer feature" for before something is in the Manifest: it's a significant addition in addition to Manifest signing. But like all key handling, but it has to be done right.
(In reply to emdee_is from comment #0) > From a security point of view, I think it's a bad idea to cache copies of > OpenPGP keys. It's up to the originator to say how to find his keys and you > don't want to introduce a mechanism where your cache could be out of date or > compromised relative to the source. > > For example: > > grep -l 'SRC_URI="https://dev.gentoo.org/~sam/distfiles/' > /usr/portage/sec-keys/*/*d > openpgp-keys-aacid/openpgp-keys-aacid-20220603.ebuild > openpgp-keys-bradking/openpgp-keys-bradking-20220407.ebuild > openpgp-keys-danielveillard/openpgp-keys-danielveillard-20210514.ebuild > openpgp-keys-file/openpgp-keys-file-20220611.ebuild > openpgp-keys-joelrosdahl/openpgp-keys-joelrosdahl-20220409.ebuild > openpgp-keys-kamildudka/openpgp-keys-kamildudka-20220525.ebuild > openpgp-keys-karelzak/openpgp-keys-karelzak-20220331.ebuild > openpgp-keys-libidn/openpgp-keys-libidn-20220621.ebuild > openpgp-keys-midipix/openpgp-keys-midipix-20210426.ebuild > openpgp-keys-nettle/openpgp-keys-nettle-20220603.ebuild > openpgp-keys-teemutoivola/openpgp-keys-teemutoivola-20210426.ebuild > > What's the rationale for this? Who is ~sam? I never asked him to cache GPG > keys for me. Why should I trust him to cache the keys that I will be using > to verify my downloads from a mirror? Because he's the developer you've trusted to not add malicious code into the packages you use. By using Gentoo, you're already implicitly trusting every developer. The sec-keys category isn't unique at all in this regard. *** This bug has been marked as a duplicate of bug 864262 ***
(In reply to emdee_is from comment #0) > From a security point of view, I think it's a bad idea to cache copies of > OpenPGP keys. It's up to the originator to say how to find his keys and you > don't want to introduce a mechanism where your cache could be out of date or > compromised relative to the source. > > For example: > > grep -l 'SRC_URI="https://dev.gentoo.org/~sam/distfiles/' > /usr/portage/sec-keys/*/*d > openpgp-keys-aacid/openpgp-keys-aacid-20220603.ebuild > openpgp-keys-bradking/openpgp-keys-bradking-20220407.ebuild > openpgp-keys-danielveillard/openpgp-keys-danielveillard-20210514.ebuild > openpgp-keys-file/openpgp-keys-file-20220611.ebuild > openpgp-keys-joelrosdahl/openpgp-keys-joelrosdahl-20220409.ebuild > openpgp-keys-kamildudka/openpgp-keys-kamildudka-20220525.ebuild > openpgp-keys-karelzak/openpgp-keys-karelzak-20220331.ebuild > openpgp-keys-libidn/openpgp-keys-libidn-20220621.ebuild > openpgp-keys-midipix/openpgp-keys-midipix-20210426.ebuild > openpgp-keys-nettle/openpgp-keys-nettle-20220603.ebuild > openpgp-keys-teemutoivola/openpgp-keys-teemutoivola-20210426.ebuild > > What's the rationale for this? Who is ~sam? I never asked him to cache GPG > keys for me. Why should I trust him to cache the keys that I will be using > to verify my downloads from a mirror? > > Especially when the keys have easy to retrieve canonical sources like : > - https://savannah.gnu.org/project/release-gpgkeys.php > - https://keyserver.ubuntu.com/pks/lookup > - https://pgp.surfnet.nl/pks/lookup > > Even if the key is embedded in an HTML page I think it would be more > transparent to pull down the key with FETCHCOMMAND and pipe it through a > simple sed script to keep the key uncached. Most of these sites don't have stable content. But I agree with using direct sources from upstream where possible where they do. > > I think verify-sig is a great new feature of Gentoo as an added layer of > defence-in-depth, and really appreciate all of the work it takes to do this. > It's not just a "developer feature" for before something is in the Manifest: > it's a significant addition in addition to Manifest signing. But like all > key handling, but it has to be done right. It might, might, *might* be worth exploring some way for users to maintain their own keyrings and inject their own paths (the eclass could allow overrides). But you'd need to provide an implementation for that.
I understand the need for stability, but I was surprised to see the caching from easy to retrieve canonical sources like : - https://savannah.gnu.org/project/release-gpgkeys.php - https://keyserver.ubuntu.com/pks/lookup - https://pgp.surfnet.nl/pks/lookup Let me modify my request to be: "we should be using direct sources from upstream where possible, including for example all of the above list"... I think in many cases, GPG key owners will have a "preferred" keyserver, and if they don't put their key in a simple URL, we should use that. (I envisage individuals contributing their own sec-keys ebuilds - I would certainly want to.) And by extension, where there is not "preferred" keyserver by the originator, then Gentoo could have its "preferred keyserver" that would then make it easy to upgrade or change the "preferred keyserver" URL across sec-keys/*/*d, it case the GPG world had problems. (It might be worth a eclass function to wrap the notion of a "preferred keyserver"?)
This is NOT a duplicate of https://bugs.gentoo.org/864262 - I intentionally added this as a separate issue, because that is a totally different kind of portage voodoo caching/MIRRORing of GPG keys, unseen to the ebuild writer, so please remove the RESOLVED DUPLICATE.
(In reply to emdee_is from comment #3) > I understand the need for stability, but I was surprised to see the caching > from easy to retrieve canonical sources like : > - https://savannah.gnu.org/project/release-gpgkeys.php They're not pinned at a particular time, which isn't ideal, but they are stable between fetches, so yes, we could probably fetch, even though we dislike doing that (because it's going to break at some point). > - https://keyserver.ubuntu.com/pks/lookup Ubuntu results are not stable. > - https://pgp.surfnet.nl/pks/lookup > > Let me modify my request to be: "we should be using direct sources from > upstream where possible, including for example all of the above list"... > > I think in many cases, GPG key owners will have a "preferred" keyserver, and > if they don't put their key in a simple URL, we should use that. (I envisage > individuals contributing their own sec-keys ebuilds - I would certainly want > to.) I don't see why we would add them without something using them. Users could do it in an overlay if they want. > > And by extension, where there is not "preferred" keyserver by the > originator, then Gentoo could have its "preferred keyserver" that would then > make it easy to upgrade or change the "preferred keyserver" URL across > sec-keys/*/*d, it case the GPG world had problems. (It might be worth a > eclass function to wrap the notion of a "preferred keyserver"?) Note that we don't do any key refreshes for these. That also could be added as an extension in theory.
(In reply to emdee_is from comment #4) > This is NOT a duplicate of https://bugs.gentoo.org/864262 - I intentionally > added this as a separate issue, because that is a totally different kind of > portage voodoo caching/MIRRORing of GPG keys, unseen to the ebuild writer, > so please remove the RESOLVED DUPLICATE. Gentoo developers are well aware of the mirroring system: https://devmanual.gentoo.org/general-concepts/mirrors/index.html.
(In reply to emdee_is from comment #4) > This is NOT a duplicate of https://bugs.gentoo.org/864262 - I intentionally > added this as a separate issue, because that is a totally different kind of > portage voodoo caching/MIRRORing of GPG keys, unseen to the ebuild writer, > so please remove the RESOLVED DUPLICATE. Both issues are invalid for the same reason: verify-sig isn't making a security guarantee that the Gentoo version is equivalent to upstream's.
