In order to be able to verify the portage snapshots the stage-3 should contain GPG. Otherwise the user must either obtain and verify the snapshots using the installation media or use an unverified snapshot to compile gpg and be able to do future verification.
I don't see why this should be limited to hardened stages. If we are securing things with gpg signatures then we should allow all users to take advantage. I'm all for this, but I really don't want to make 50 individual changes relating to this, right now it's not possible to check most of the signatures automatically without things like gentoo-keyring being available yet. I'd prefer to wait on this until we have a proper implementation ready.
Sorry, but no. A stage3 is the result of emerge -e system. If you want gpg on the stages, you need to add gpg to the system set. Also in my view, by design, if you want to confirm a stage, you need to use external tools, not tools inside it. We already have gnupg in the minimal and admin CDs. I'm leaving this open so we can discuss, but in my view this should be closed as INVALID.
I agree entirely that there is no way in hell we are adding gpg to the system set. However, bug 393445.
The gentoo-keys project will make this simple. There will be a simple cli command to verify release media like stages, installcd's,... I also think it should not be part of the system set, but something that could be installed early in the install process like cron, and other system tools. At the user's discretion. Portage itself will also get gentoo-keys support built-in later on during the development of gentoo-keys. Including gentoo-keys on all install media is a definite yes from me. We could also make a gentoo-keys package available in other formats like an RPM pkg to make verification from other distros easy.
(In reply to Rick Farina (Zero_Chaos) from comment #3) > I agree entirely that there is no way in hell we are adding gpg to the > system set. However, bug 393445. I just noticed this bug was linked to bug 393445. I disagree with gpg being in the stages per my reasoning above. Unless gpg becomes a dep of the gentoo-keys project and we add that to stages.
gpg is a dep of gentookeys. But I also agree that it should not be part of a stage3. However, as I stated earlier, the install media should have gpg and gentoo-keys installed and can download and verify the stage3 and several other key items to be installed in the unpacked stage3 like a binary keyring, possibly a gpg binpkg. From there it is a matter of what the user wants installed at their discretion. Gentoo-keys itself is a python based application so is not hard to even copy from the install media into the stage3 for it to work in the chrooted environment. But that would still require gpg be installed.
(In reply to Francisco Blas Izquierdo Riera from comment #0) > In order to be able to verify the portage snapshots the stage-3 should > contain GPG. Otherwise the user must either obtain and verify the snapshots > using the installation media or use an unverified snapshot to compile gpg > and be able to do future verification. This is a weak reason. All stage3's depend on some other installation already being in place in order to be useful. To even download a stage3 you must have a function operating system. There verifying the snapshots via installation medium is a minor onus on the tin hat wearing user.
The user can verify stage3 during the installation, but an initial `emerge-webrsync` with GPG verification is not possible (related https://bugs.gentoo.org/show_bug.cgi?id=534218). The initial portage tree is transfered by using HTTP. There should be a way to install Gentoo (using the Handbook) with complete GPG verification. I am aware that I could use GPG from the live system of choice and manually extract the portage tree.
(In reply to Martin Zimmermann from comment #8) > The user can verify stage3 during the installation, but an initial > `emerge-webrsync` with GPG verification is not possible (related > https://bugs.gentoo.org/show_bug.cgi?id=534218). The initial portage tree is > transfered by using HTTP. > > There should be a way to install Gentoo (using the Handbook) with complete > GPG verification. I am aware that I could use GPG from the live system of > choice and manually extract the portage tree. Martin has basically summarized my point there, either we restore the old tar based way of unpacking the portage tree and explain how to verify it's keys or we provide gpg so emerge-webrsync can be used as the portage tree is downloaded unencrypted and unverified otherwise.
Well, my understanding is that the releng team is aiming to making stage4's the normal release media and making stage3 more stripped down in order to reduce the @system set. A stage4 could be made to include gkeys. I am currently working on portage integration of gkeys for Manifest file verification the new squashfs sync module. So, a stage4 could be likely with gkeys and gpg installed, making the base stage install fully capable of verifying anything it needs to.
I'm looking forward to the stage4 releases and gentoo-keys! :) Is there anywhere we can track their process? PS: Another workaround I've used is to securely copy the portage tree from a trusted machine to the target machine during installation, then emerge gpg and setup webrsync-gpg.
(In reply to Brian Dolbec from comment #10) > Well, my understanding is that the releng team is aiming to making stage4's > the normal release media and making stage3 more stripped down in order to > reduce the @system set. A stage4 could be made to include gkeys. I am > currently working on portage integration of gkeys for Manifest file > verification the new squashfs sync module. So, a stage4 could be likely > with gkeys and gpg installed, making the base stage install fully capable of > verifying anything it needs to. Because of the whole discussion in this bug and the above, I'm going to close this bug as INVALID. If / when we start shipping stage4 and if gpg is made a dep of gkeys, it will get into that stage.
*** Bug 572462 has been marked as a duplicate of this bug. ***
