[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 Fri, 08 Aug 2014 11:34:54 -0700 as excerpted:

> On Thu, Aug 7, 2014 at 2:18 PM, Duncan <1i5t5.duncan@×××.net> wrote:
>> Mark Knecht posted on Thu, 07 Aug 2014 11:16:23 -0700 as excerpted:
>>
>>> I don't see any evidence that emerge checked what it downloaded, but
>>> maybe those checks are only done when I really build the code?
>>
>> Here's what happens.
>>
>> FEATURES=webrsync-gpg simply tells the webrsync stuff to gpg-verify the
>> snapshot-tarball that webrsync downloads.  Without that, it'd still
>> download it the same, but it wouldn't verify the signature.  This
>> allows people who use the webrsync only because they're behind a
>> firewall that wouldn't allow normal rsync, but who don't care about the
>> gpg signing security stuff, to use the same tool as the people who
>> actually use webrsync for the security aspect, regardless of whether
>> they could use normal rsync or not.
>>
> And to clarify, I believe this step is responsible for putting into
> place on a Gentoo machine much of what's in /usr/portage, most
> specifically in the app categorization  directories.

Yes.  It's basically the entire $PORTDIR tree (/usr/portage/ by default), 
the app categories and ebuilds plus digest files and patches, eclasses, 
metadata, the profiles, the whole thing.

That's what emerge sync would normally update (via rsync), and
emerge-webrsync replaces the normal emerge sync with a tarball download, 
signature verify if FEATURES=webrsyncgpg, and tarball extraction to 
$PORTDIR (while normally /usr/portage/, my $PORTDIR is set to put it 
elsewhere).

The only bits of $PORTDIR that wouldn't be included would be $DISTDIR
(/usr/portage/distfiles/ by default, but again I have mine set to 
something else), as source files are downloaded and hash-verified against 
against the hash-digest stored in the digest files (which are part of the 
signed tarball), and $PKGDIR (/usr/portage/packages/ by default, but 
again, I've set the variable to put them elsewhere), since that's binpkgs 
that portage creates if you have FEATURES=buildpkg or FEATURES=buildsyspkg 
set.

Additionally, anything else that you configure to be placed in $PORTDIR 
won't be in the tarball, as you've configured that for yourself.  Here, I 
have layman's overlays under $PORTDIR as well (the storage setting in 
layman.conf, by default set to /var/lib/layman), with an appropriate 
rsync-exclude set so emerge sync doesn't clear them out when I sync.  
Were I to switch to webrsync I might have to do something different as I 
guess webrsync would clear them out.

Which reminds me, in all the discussion so far we've not talked about 
overlays or layman.  But since that is optional, it can be treated as a 
separate topic.  Suffice it to say here that the webrsync discussion 
does /not/ cover overlays, etc, only the main gentoo tree.

> In the old days the Gentoo Install Guide used to have us download the
> portage snapshots for a location such as
>
> http://distfiles.gentoo.org/snapshots/
>
> That's now been replaced by a call to emerge-webrsync so newbies might
> not have that view.

Good point.  I had noticed that change in passing when I found and 
referenced the handbook webrsync stuff too, but didn't think it worth 
mentioning.  But you're correct, without the perspective of what it 
replaced, newbies might miss the connection.

> Additionally, even if we're downloading the snapshot
> tarball it appears, at least on my system, it's deleted after it's
> expanded/ Or at least it's not showing up in a locate command.

Interesting.  Deleting by default after extraction does make sense, 
however, since otherwise you'd have an ever-growing cache of mostly 
identical content with only incremental change, tho I imagine there's 
some sort of config option to turn it off, in case you don't want it 
deleted.

Tho I don't use locate here and in fact don't even have it installed.
I never found it particularly useful.  But are you sure locate would show 
it anyway, given that locate only knows about what is indexed, and the 
indexing only runs periodically, once a day or week or some such?  If it 
hasn't indexed files since you started doing the emerge-webrsync thing, 
it probably won't know anything about them, even if they are kept.

(Actually, that was my problem with locate in the first place.  My 
schedule is never regular enough to properly select a time when the 
computer will be on to do the indexing, yet I won't be using it for 
something else so it can do the indexing without bothering whatever else 
I'm doing.  Additionally, since it only knows about what it has already 
indexed, I could never completely rely on it having indexed the file I 
was looking for anyway, so it was easier to simply forget about locate 
and to use other means to find files.  So at some point, when I was doing 
an update and the locate/slocate/whatever package was set to update, 
since I had never actually used it in years, I just decided to unmerge it 
instead.  That must have been years ago now, and I've never missed it...)

-- 
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