Portage Security

This page aims to answer the question "How can I dispel doubts regarding the security of the Gentoo ebuild repository on a system?" That is, to cryptographically ensure each file under /var/db/repos/gentoo 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.

Note
Systems using systemd-resolved from <=sys-apps/systemd-238 causes gpg keyserver refresh failures. See this GitHub issue for more information.

webrsync

Whenever emerge --sync is run, the repos.conf sync-type set to webrsync and sync-webrsync-verify-signature option is enabled, the downloaded tarball is always checked against Gentoo release keys provided by sec-keys/openpgp-keys-gentoo-release 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 emerge --sync:

root #rm --recursive --force $(portageq get_repo_path / gentoo)/*

root #emerge --sync

Finally, reset the proper profile symlink using eselect profile.

Configuration

1. Ensure that Portage has the rsync-verify USE flag enabled.
2. In repos.conf, set sync-type to webrsync and enable the sync-webrsync-verify-signature option
3. Make sure that emerge --sync 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 /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 have not been compromised.
2. That the content on the file that SRC_URI point to in sec-keys/openpgp-keys-gentoo-release 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 rsync-verify USE flag enabled.
2. Make sure that emerge --sync 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 gemato verify -K /usr/share/openpgp-keys/gentoo-release.asc /var/db/repos/gentoo
3. A manifest mismatch error should result.
4. Go a step further and update the manifest with ebuild foobar-1.2.3.ebuild manifest
5. Run gemato verify -K /usr/share/openpgp-keys/gentoo-release.asc /var/db/repos/gentoo
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 sec-keys/openpgp-keys-gentoo-release.
2. Add gentoo-mirror repo to the system's repos.conf file.
3. In repos.conf, set sync-uri to https://anongit.gentoo.org/git/repo/sync/gentoo.git.
4. In repos.conf, 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. emerge --sync 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 to 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 Gentoo ebuild repository syncs. 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.

See also

• Portage — the official package manager and distribution system for Gentoo.