[gentoo-amd64] Re: "For What It's Worth" (or How do I know my Gentoo source code hasn't been messed with?)

[Duncan]

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