Hi there! It would be nice to somehow limit how portage trust GPG keys in /etc/portage/gnupg. As for now, if user will add some key there as trusted (to be use with alternate binrepos with FEATURES=binpkg-request-signature), as far as I understand things correctly, portage will trust this key to sign any packages in any binrepos (or even more globally). This potentially can help some attacks (including MitM) (especially in cases of leaked keys) even on other binrepos (and maybe not even only "bin"). Reproducible: Always
Can you describe the threat model this would help with? Note that you can't specify "I only want a binpkg for this package from this Binhost" anyway. Not getting what this actually helps with.
Let's assume following hypothetic situation. 1) there is some binhost mirror that has it's audience. Let it be, say, yandex ( https://mirror.yandex.ru/gentoo-distfiles/releases/amd64/binpackages/ ) or city-wide, hosted by some university, say TSPU ( https://mirror.tspu.ru/gentoo/releases/amd64/binpackages/ ), or even MEPHI ( http://mirror.mephi.ru/gentoo-distfiles/releases/amd64/binpackages/ ) ) 2) let's assume attacker is the worker of the company/university. (well, MEPHI mirror doesn't even have HTTPS, and listed on the official mirrors list on gentoo.org just with "http", so attacker don't even need to be a worker, it will be enough to just MitM the victim while being on the same LAN) 3) let's assume attacker is also owner of some binrepo that only provides few packages (say, let it be neovim-9999 with nightly or even per-each-new-upstream-commit rebuilds). And it doesn't do any criminal there, and don't upload (nor want to upload) compromised packages there. Or maybe binrepo owner is not an attacker at all, but just compromised their signing key over attacker from p.2 Anyway, the case that attacker got their key. And they (binrepo owner) signs their packages with their own key. And recommended users of their binrepo to perform, say: ``` getuto && gpg --homedir /etc/portage/gnupg --keyserver hkps://keys.opengpg.org --recv-keys <signing_key> && echo -e 'trust\n5\ny\nquit\n' | gpg --homedir /etc/portage/gnupg --no-tty --command-fd 0 --edit-key <signing_key> && gpg --homedir /etc/portage/gnupg --check-trustdb ``` for them to be able use packages from this binrepo without disabling signature verification. Here, still nothing criminal, but then... Attacker either uploads malicious binpackage on the mirror (remember, attacker is a worker of mirror hoster), or, in case of MEPHI it is even less risky: just MitMs victim and substitutes binpkg when they fetched some binpacks from mirror. And, as far as I understand the mechanisms behind that, portage won't complain on such malicious packages (as they are signed by key the key, marked as trusted). // Also, attacker can potentially be not even a worker, but somebody from law-enforcement services.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #2) > Here, still nothing criminal, but then... > > > Attacker either uploads malicious binpackage on the mirror (remember, > attacker is a worker of mirror hoster), or, in case of MEPHI it is even less > risky: just MitMs victim and substitutes binpkg when they fetched some > binpacks from mirror. > > And, as far as I understand the mechanisms behind that, portage won't > complain on such malicious packages (as they are signed by key the key, > marked as trusted). Any binhost can already serve whatever packages they please. The only distinction restricting keys per repo would make, is the MiTM case you describe. In such a case, a first party attacker has the choice of either offering you malicious binaries from the binhost they have control of and which you already trust them to be honest and trustworthy for, or using an MiTM attack to... What? What is the purpose of sending you the exact same malicious binary via a MiTMed mirror vs the binhost they control? Why does the former need protecting against and not the latter? Is this about discoverability? The attacker doesn't have to publish the malicious binaries on their site, so other people won't see it. But this is hardly a real issue because they can just offer you different results from anyone else -- a server can serve different contents to different IP addresses -- or just offer a 30-second window where the binpkgs are malicious. In the event of a compromised key, this somehow relies on the idea that if you have two binhosts and one gets hacked, a MiTM is only a viable attack against the other binhost. It's not clear why this is a likely scenario.
