Gentoo AMD64 Handbook, in its section "Installing the Gentoo base system" and subsection "Installing an ebuild repository snapshot from the web", recommends to use # emerge-webrsync command "to fetch the latest snapshot from one of Gentoo's mirrors and install it onto the system" just after fetching and untarring stage3, but this is simply does not work if you have previously set webrsync-gpg feature in make.conf, which you SHOULD do because of security reasons, because stage3 still does not have the necessary tools to check the gpg signure of the portage snapshot. This bug can be fixed in one of the following two ways: 1) to include the tools necessary for checking Gentoo team signatures into the stage3; 2) to change the "Installing an ebuild repository snapshot from the web" subsection of the Gentoo Handbook by deleting the recommendation to use emerge-webrsync command and insetting the instructions similar to those that were used while fetching and untarring stage3. I hit this bug at least twice this year, installing Gentoo in January and September 2018, so I am pretty sure it is still there. :) The similar situation was also described in a still unfixed bug 572590 yet in January 2016! The author of the bug then wrote: "With webrsync-gpg in FEATURES in make.conf, webrsync loops through GENTOO_MIRRORS if pubring.gpg does not exist." He then suggested that the emerge-webrsync command "should stop attempting to download anything and throw an error message recommending to emerge app-crypt/gentoo-keys." However, it is impossible in the situation described in this bug because just after downloading stage3 there is no portage tree on the system at all and so it is impossible to install any package. Of course, it is still possible to temporarly disable webrsync-gpg feature in make.conf and run emerge-webrsync command to fetch the portage stapshot. However, in this case the fetched portage snapshot remain unverified, which imposes security risk and thus is unacceptable.
Gentoo has a long history of similar bugs. See, e.g., bug 534218 filed yet in 2015. May be, it is time to finally fix it?
The mentioned above bug 572590 has already been assigned to Portage Development and has been abandoned for about 3 years. I think that the fact that the current Gentoo Handbook for years does not allow to install Gentoo in a secure way should be brought to the attention of Gentoo Counsil.
Everything has changed, since bug 661838 the preferred way to make emerge-webrsync verify snapshot snapshot signatures is to configure /etc/portage/repos.conf like this: > [gentoo] > sync-type = websync > sync-webrsync-verify-signature = true The /usr/share/portage/config/repos.conf file has this setting for the gentoo repository, so there's no need to specify it in your repos.conf: > sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc The stage3 tarballs already include app-crypt/openpgp-keys-gentoo-release, app-crypt/gnupg, and app-portage/gemato. The default rsync configuration these things to verify rsync manifest signatures by default. Also, since bug 660410, the data will be quarantined if signature verification fails.
At least documents need to be updated to use the sync-webrsync-verify-signature configuration posted in comment #3: https://wiki.gentoo.org/wiki/Handbook:Parts/Working/Features#Validated_Gentoo_repository_snapshots https://wiki.gentoo.org/wiki/Portage_Security#webrsync
Can do!
Please see the latest updates in bug 597800. The default is now secure even with `emerge-webrsync` and `webrsync-gpg` is deprecated as a FEATURE.
