Gentoo: use git for portage synchronization

By default, Gentoo is using the rsync protocol to distribute it’s portage tree. For synchronizing a lot of smaller files, this protocol is rock-solid.

However, this method comes with a small drawback. To ensure the integrity of the downloaded files, they are signed with an OpenGPG key. First, the files are downloaded into a quarantine directory. Afterwards, portage is trying to validate the signatures and only if the signatures match the local portage tree will be overwritten with the newly synced files. The problem with this method is that the signature check is pretty slow, especially on lower-end systems. In my experience, it can take up to several minutes until the update is completed.

Fortunately, we can tell portage to use git instead of rsync for updating the portage tree.

Since the Gentoo developers are only accepting signed git commits, we don’t need additional signature checks here since the commits themselves can be considered as valid. Since running emerge --sync is nothing more than a simple git pull, the synchronization only takes a couple of seconds.

The configuration takes place in the file /etc/portage/repos.conf/gentoo.conf which should then look like this:

main-repo = gentoo

location = /var/db/repos/gentoo
sync-type = git
sync-uri =
auto-sync = yes
sync-git-verify-commit-signature = yes
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc

After changing the configuration file, it’s necessary to delete the local portage tree (which resides in /var/db/repos/gentoo by default) once since the initial git clone will fail otherwise.

As you can see, the configuration is now looking a lot slimmer. All lines beginning with sync- are not needed anymore and can either be deleted or commented out.

One note regarding the sync-uri: In addition to the servers hosted by the Gentoo infrastructure team it’s also possible to use the GitHub mirror hosted at However, the GitHub mirror should only act as a fallback solution since it’s lacking some metadata that need to be manually generated by using egencache.

In case you are using your own (additional) repositories, it is still possible to include them by using rsync since the synchronization options can be configured per repository.

Update: As holgersson pointed out in his comment, the git synchronisation doesn’t do any verification at all. Therefore it’s recommended to enable sync-git-verify-commit-signature as shown above. Thank you!


  1. Hi,

    looks as you actually disabled the verification completly. Please take a look into ‘man portage’ and search for sync-git-verify-commit-signature, which is disabled by default, so in your case aswell.

    Your approach was right though – if you take a signed git tree and trust sha1 in git enough you can verify the ‘youngest’ commit and assume that everything older is signed aswell.

    By the way, you can also try out if modifying the rsync verification jobs might help a bit: see sync-rsync-verify-jobs (which defaults to 1).


    1. Hi,

      thanks a lot for your comment! I’ll take a closer look to the signature verification and update this article according to your recommendations.

      Thank you!

  2. For some reason, activating sync-git-verify-commit-signature with the GitHub mirror results in failure to verify the signature. Using the Gentoo hosted GIT server works flawlessy.

    1. Indeed – the GitHub mirror is missing quite a lot of metadata. Not only the signature verification is broken, you’ll also notice that e.g. the ‘eix’ command won’t work properly since the GitHub mirror lacks all information required to populate eix’ internal database.

Leave a Reply

Your email address will not be published. Required fields are marked *