Portage Security

This page Article description::aims to answer the question "How can I dispel doubts regarding the security of the Gentoo ebuild repository on a system?" That is, to ensure each file under is entirely composed of code written by or reviewed by Gentoo developers.

This question is answered differently whether the webrsync, rsync, git-mirror, or canonical git repositories directly method is used.

webrsync
Whenever is run with the appropriate settings, the downloaded tarball is always checked against Gentoo release keys which are provided by.

The only caveat is that this method doesn't do further checking after having unpacked the tarball. So, if the Gentoo repository was compromised before the webrsync, it's possible that it's still compromised. If the state of the Gentoo repository is in question, wipe it out before doing.

Configuration
The public key used to verify signatures is provided by. In the case it's not updated in a timely manner, manually update those keys with:

Dispelling doubt
Seeing "Checking signature..." should be enough to dispel doubts. Also, reading the contents of `/usr/bin/emerge-webrsync` which is small enough to be easily audited.

Hardcore users can arrange a man-in-the-middle attack and check that verification fails.

Verifying trust

 * 1) That the Gentoo's release keys haven't been compromised.
 * 2) That the content on the file that SRC_URI point to in app-crypt/gentoo-keys is actually the Gentoo release keys
 * 3) Everything that is needed to trust in the "canonical git repos" method.

rsync
Portage 2.3.21+ supports recursive signed manifests checking. Project:Portage/Repository Verification explains how it works.

Configuration

 * 1) Ensure that portage has the  flag
 * 2) Make sure that  emits "Using keys from ..." and "Valid OpenPGP signature found"
 * 3) Never miss errors during --sync

Dispelling doubt
Simulate malicious injection:


 * 1) Change an ebuild
 * 2) Run
 * 3) A manifest mismatch error should result
 * 4) Go a step further and update the manifest with
 * 5) Run
 * 6) A mismatch error will occur

Verifying trust
Same thing as with webrsync. With repository verification, the integrity of rsync mirrors are no longer an issue. So, it is not less secure than webrsync.

git-mirror repositories
The gentoo git mirror is a git repo that delivers the equivalent of the rsync method, that is, the content of the canonical git repository but with DTD, GLSA, news, and XML schema information attached and an up to date portage cache generated.

Every commit is signed by either the developer or the "repomirrorci@gentoo.org" PGP key. So, integrity is ensured through the recent repository option.

Configuration

 * 1) Install.
 * 2) Add gentoo-mirror repo to your repos.conf
 * 3) In repos.conf, set  and enable the  option

Dispelling doubt

 * 1) Make a local clone of the mirror
 * 2) Set the  to the local clone
 * 3) Add a commit on top of it
 * 4)  should complain

Verifying trust

 * 1) The integrity of the "repomirrorci@gentoo.org" PGP key.
 * 2) The CI server isn't compromised (which would compromise the key).
 * 3) Everything that is needed to trust in the "canonical git repos" method.

canonical git repositories
All methods above take their content from the same source: The canonical Gentoo repository. Every commit in this repository is required so be signed by developers using PGP keys listed in Gentoo's LDAP. Those keys are listed in the Current Gentoo developers page.

Why isn't this method preferred? Because this repo doesn't contain everything it needs to be fully functional. It needs to be augmented with data repos and a portage cache needs to be regenerated at each update (which can take a little while).

Despite this method being more hassle, it has the advantage of having a different trust model: trusting release keys and infra is no longer required for portage tree updates. Directly trusting developers and the strength of their PGP web of trust.

Configuration
Follow instructions from Gentoo ebuild tree from scratch.

Dispelling doubt
Because this method requires self-configuration of the verification processes, there shouldn't be much doubt left once complete.

Verifying trust

 * 1) That the web of trust of Gentoo developers is strong.
 * 2) That Gentoo developers have good practices regarding the security of their private PGP key.

The great thing about this trust model is that it doesn't rely on infrastructure integrity. Sure, a developer's key can be compromised but it's something that can easily be spotted (especially by the compromised developer. "hey! that commit isn't mine!") and integrity and trust is easy to bring back (review all recent commits by this developer and remove malicious ones). There is no single point of failure.