It was a discussion at Pentoo during which I realised that verify-sig can be improved. See the following bug report for details: https://github.com/pentoo/pentoo-overlay/issues/1170 One of the problem is that verify-sig would fail to detect a compromised mirror server. The problem is that both .asc file and sec-keys/openpgp-keys* packages are getting downloaded from the same (untrusted) location. So I suggest the following: - add RESTRICT="mirror" to all sec-keys/openpgp-keys* packages - add VERIFY_SIG_OPENPGP_KEY_HASH option so that Gentoo developers could specify a hash of the key in the ebuild.
I don't understand the value here. The only point of compromise that makes sense I can see is trying to fetch a key (as a developer, before a Manifest is committed) for the first time and then contacting GENTOO_MIRRORS. But e.g. pkgdev commit deliberately doesn't use mirrors for Manifest regeneration because it's a waste of time -- we don't expect to find the file there. The arguments in the bug about the tree being compromised don't compute. If the tree is compromised, you'd just tamper with the ebuilds (inc. the verify-sig ones) themselves, or shove some evil bash in an eclass. I don't see what case this helps with at all.
From a security point of view, I think it's a bad idea to cache copies of OpenPGP keys, *no matter what the scenario*. 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. I'm not even comfortable with the other caching some of the keys ebuilds are doing: https://bugs.gentoo.org/864819 grep -l 'SRC_URI="https://dev.gentoo.org/~sam/distfiles/' /usr/portage/sec-keys/*/*d I think verify-sig is a great new feature of Gentoo as an added layer of defence-in-depth; it's not just a "developer feature" for before something is in the manifest: it's a significant addition on top of Manifest signing. I don't see the value of introducing a potential point of failure in key handling if it's not needed, so I would like to ask you to reinstate the request to: - add RESTRICT="mirror" to all sec-keys/openpgp-keys* packages Adding a VERIFY_SIG_OPENPGP_KEY_HASH option so that Gentoo developers could specify a hash of the key in the ebuild can't hurt either.
(In reply to emdee_is from comment #2) > From a security point of view, I think it's a bad idea to cache copies of > OpenPGP keys, *no matter what the scenario*. 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. verify-sig isn't adding anything in terms of security, though, so hardening it in this way doesn't gain us anything.
*** Bug 864819 has been marked as a duplicate of this bug. ***
(In reply to emdee_is from comment #2) > From a security point of view, I think it's a bad idea to cache copies of > OpenPGP keys, *no matter what the scenario*. 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. > > I'm not even comfortable with the other caching some of the keys ebuilds are > doing: https://bugs.gentoo.org/864819 > grep -l 'SRC_URI="https://dev.gentoo.org/~sam/distfiles/' > /usr/portage/sec-keys/*/*d > This makes no difference because you already have to trust the SRC_URI in the ebuild using verify-sig, the bash in it, and any patches. In addition to that, and this is why they're mirrored to my devspace in the first place in this instance, keyservers don't tend to give stable URLs. I use stable URLs if available. > I think verify-sig is a great new feature of Gentoo as an added layer of > defence-in-depth; it's not just a "developer feature" for before something > is in the manifest: it's a significant addition on top of Manifest signing. > In terms of threat model, it only makes sense for two types of issue: 1. developer makes a mistake before committing Manifest (commits an upstream dodgy tarball but they didn't realise) - verify-sig will help catch this if the upstream malware'd tarball was not signed; 2. ... same as 1. but developer didn't notice, and you notice for them, because the developer didn't have verify-sig on despite setting up for their packages (very unlikely). > I don't see the value of introducing a potential point of failure in key > handling if it's not needed, so I would like to ask you to reinstate the > request to: > > - add RESTRICT="mirror" to all sec-keys/openpgp-keys* packages > I already said how this makes no difference? > Adding a VERIFY_SIG_OPENPGP_KEY_HASH option so that Gentoo developers could > specify a hash of the key in the ebuild can't hurt either. This would make no difference at all? If a Gentoo developer is doing something evil, they'd change the hash?
(In reply to emdee_is from comment #2) > From a security point of view, I think it's a bad idea to cache copies of > OpenPGP keys, *no matter what the scenario*. It's up to the originator to You can't say "no matter what the scenario" then not describe a single one where it helps.
@Sam James Caching keys *is* the scenario, regardless of if the mirror is compromised (or altered on the fly by a MITM). The moment you cache keys, then you may be distributing keys that have been revoked or changed and you don't want to introduce a mechanism where your cache could be out of date or compromised relative to the source. Let the client fetch the keys to make sure the key is valid at that time. @John Helmert III This is not a duplicate of of this bug: 864819 I created them both and they refer to different caching. I strongly disagree that verify-sig isn't adding anything in terms of security. The obvious "scenario" is that a key is compromised and revoked in between when the source made it into the Manifest and the client installing it. In addition, it adds a layer of defence-in-depth above the signing of manifests. For things like the kernel or firmware, security conscious installations may require signature verification, no matter what the package manager is. Gentoo's support of key verification is a big plus, not just overhead. This bug is not INVALID so please reopen: - add RESTRICT="mirror" to all sec-keys/openpgp-keys* packages
(In reply to emdee_is from comment #7) > @Sam James Caching keys *is* the scenario, regardless of if the mirror is > compromised (or altered on the fly by a MITM). The moment you cache keys, > then you may be distributing keys that have been revoked or changed and you > don't want to introduce a mechanism where your cache could be out of date or > compromised relative to the source. Let the client fetch the keys to make > sure the key is valid at that time. > > This bug is not INVALID so please reopen: > - add RESTRICT="mirror" to all sec-keys/openpgp-keys* packages Revocation won't be picked up by RESTRICT="mirror" anyway as the checksum would change. What you want is adding key refreshes like we do for emerge --sync.
(In reply to emdee_is from comment #7) > @Sam James Caching keys *is* the scenario, regardless of if the mirror is > compromised (or altered on the fly by a MITM). The moment you cache keys, > then you may be distributing keys that have been revoked or changed and you > don't want to introduce a mechanism where your cache could be out of date or > compromised relative to the source. Let the client fetch the keys to make > sure the key is valid at that time. You're suggesting a system of mutable keys which would be incompatible with the statefulness of the Gentoo tree (and thus verify-sig). > @John Helmert III This is not a duplicate of of this bug: 864819 > I created them both and they refer to different caching. Actually, you're not the reporter of this bug. > I strongly disagree that verify-sig isn't adding anything in terms of > security. > The obvious "scenario" is that a key is compromised and revoked in between > when the source made it into the Manifest and the client installing it. In > addition, it adds a layer of defence-in-depth above the signing of > manifests. For things like the kernel or firmware, security conscious > installations may require signature verification, no matter what the package > manager is. Gentoo's support of key verification is a big plus, not just > overhead. If an attacker can manipulate manifests they can manipulate the bash in ebuilds to run anything they want (even without package installation), or add malicious patches to packages. verify-sig *cannot* defend against this, thus it adds no security over manifests. > This bug is not INVALID so please reopen: > - add RESTRICT="mirror" to all sec-keys/openpgp-keys* packages
