Mark Knecht posted on Wed, 06 Aug 2014 14:33:28 -0700 as excerpted: > OK, I've modified make.conf as such: > > FEATURES="buildpkg strict webrsync-gpg" > PORTAGE_GPG_DIR="/etc/portage/gpg" > > and created /etc/portage/gpg:
> drwxr-xr-x 2 root root 4096 Jul 6 09:42 > eix-sync seems to be working but it may (or may not) be caught in some > loop where it just keeps looking for older data. I let it go until it > got back into July and then did a Ctrl-C: > > c2RAID6 portage # eix-sync -wa > * Running emerge-webrsync > Fetching most recent snapshot ... > Trying to retrieve 20140805 snapshot from http://gentoo.osuosl.org ... > Fetching file portage-20140805.tar.xz.md5sum ... > Fetching file portage-20140805.tar.xz.gpgsig ... > Fetching file portage-20140805.tar.xz ... > Checking digest ... > Checking signature ... > gpg: Signature made Tue Aug 5 17:55:23 2014 PDT using RSA key ID > C9189250 > gpg: Can't check signature: No public key > Fetching file [repeat in a loop with older dates] > QUESTIONS: > > 1) Is the 'No public key' message talking about me, or something at the > source? I haven't got any keys so maybe i need to generate one? It's saying you need to (separately) download the *GENTOO* key using some other method, and put it in the appropriate place so it can verify the signatures its finding. Note that while I've not used webrsync, for some years (until I switched from signed kernel tarball to git-cloned kernel) I ran a script that I wrote up myself, that downloaded the kernel tarball as well as its gpg- signatures, and gpg-verified the signature on the tarball before unpacking it and going ahead with reconfiguration and build. So I have a reasonable grasp of the general concepts -- good enough I could script it -- but I don't know the webrsync specifics. But that's definitely a missing separately downloaded public key, so it can't verify the signatures on the tarballs it's downloading, and is thus rejecting them. Of course in this case such a rejection is a good thing, since if it was acting as if nothing was wrong and simply trusting the tarball even when it couldn't verify the signature, it would be broken in security terms anyway! =:^) So that's what you'll need to do, presumably based on instructions you find for getting that key and putting it in the right spot so webrsync can access it. But unfortunately since I've not used it myself, I can't supply you those instructions. Or wait! Actually I can, as google says that's actually part of the gentoo handbook! =:^) (Watch the link-wrap and reassemble as necessary, I'm lazy today. The arch doesn't matter for this bit so x86/amd64, it's all the same.) https://www.gentoo.org/doc/en/handbook/handbook-x86.xml? part=2&chap=3#webrsync-gpg Based on the above, it seems you've created the gpg directory and set appropriate permissions, but either you haven't downloaded the keys as described in the link above, or perhaps you're missing the PORTAGE_GPG_DIR setting. > 2) Once I do get this working correctly it would make sense to me that I > need to delete all existing distfiles to ensure that anything on my > system actually came from this tarball. Is that correct? Not unless you're extremely paranoid, tho it wouldn't hurt anything, just mean you blew away your cache and have more downloading to do until you have it again. Once you're verifying the tarball, part of the tarball's signed and verified contents is going to be the distfile digests. Once they're coming from the tarball, you have a reasonable confidence that they haven't been tampered with, and given the multi-algorithm hashing, even if one algorithm was hacked and the file could be faked based on only it, the other hashes should catch the problem. Of course, once you're doing this, it's even MORE important not to simply redigest the occasional source or ebuild that comes up with an error due to a bad digest. For people not verifying things to do that is one thing, but once you're verifying, simply doing a redigest yourself on anything that comes up bad directly bypasses all that extra safety you're trying to give yourself. So if a distfile tarball comes up bad, go ahead and delete it and try again, but if it comes up bad repeatedly, don't just redigest it, either check for a bad-digest bug on that package and file one if necessary, or simply wait a day or two and try again, as the problem is generally caught and fixed by then. (I've seen rumors of people on the forums, etc, suggesting a redigest at any failure, and it always scares me. Those digests are there for a reason, and if they're failing, you better make **** sure you know it's a legitimate bug (say kde making a last minute change to the tarballs after release to the distros for testing, but before public release, as they do occasionally) before redigesting. And even then, if you can just wait a couple days it should normally work itself out, without you having to worry about it or take that additional risk.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
