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 cryptographicly ensure each file under is entirely composed of code written by or reviewed by Gentoo developers.

This question is answered differently depending on the sync method in use (webrsync, rsync, git-mirror, or canonical git repositories) for the system in question.

webrsync
Whenever is run, the  sync-type set to   and sync-webrsync-verify-signature option is enabled, the downloaded tarball is always checked against Gentoo release keys provided by  package.

The only caveat is that this method does not perform further checking after the tarball has been unpacked. Therefore, if the Gentoo ebuild repository was compromised before the webrsync, it is possible that it still could be compromised. If the state of the Gentoo repository is in question, wipe it out before running :

Finally, reset the proper profile symlink using.

Configuration

 * 1) Ensure that Portage has the  USE flag enabled.
 * 2) In, set sync-type to   and enable the sync-webrsync-verify-signature option
 * 3) Make sure that  emits "Using keys from ..." and "Valid OpenPGP signature found"

Dispelling doubt
Seeing "Checking signature..." should be enough to dispel doubts. Also, reading the contents of 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 have not been compromised.
 * 2) That the content on the file that SRC_URI point to in  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  USE flag enabled.
 * 2) Make sure that  emits "Using keys from ..." and "Valid OpenPGP signature found".
 * 3) Never miss errors during  

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 items, 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 sync-git-verify-commit-signature repository option.

Configuration

 * 1) Install.
 * 2) Add gentoo-mirror repo to the system's  file.
 * 3) In, set sync-type to git and enable the sync-git-verify-commit-signature option.

Dispelling doubt

 * 1) Make a local clone of the mirror.
 * 2) Set the sync-uri value to the local clone.
 * 3) Add a commit on top of the local clone.
 * 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 ebuild 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.