Gentoo rsync considered harmful (MITM)? Straw-man solution.

[Sakaki]

Hello,

I'm in the process of updating my EFI Install Guide, and it prompted me to consider whether it is sensible to recommend new users keep their Portage tree up-to-date via rsync (as is the handbook default). The problem being, of course, that rsync is an unauthenticated protocol and as such open to man-in-the-middle (MITM) attacks (e.g., supplying corrupted ebuilds or manifests), which could easily root the machine. This is a non-trivial concern for those using Gentoo in e.g. countries with repressive regimes.

The issue has been raised before (see e.g. bug 597804), and of course there are instructions in the handbook for using webrsync-gpg, but that's quite bandwidth inefficient (and most users will only get to this after doing a standard install anyhow, by which point it may already be too late).

As a possible solution to this, an approach I have taken with my own weekly-gated Portage snapshots (for the gentoo-on-rpi3-64bit project) is to use a simple script to create a signed 'master' hash of the (recursive) contents of the /usr/portage directory (and its 'stat' metadata, under LC_ALL="C"). The script to compute this, "porthash", will win no programming awards, but may be reviewed on GitHub here. From its help text:

[nokilli]

Isn't the plan to move from rsync to git?

And then the plan is for git to move from SHA-1 to SHA-3?
_________________
Today is the first day of the rest of your Gentoo installation.

[Sakaki]

Agreed, syncing the repo via git over an authenticated channel (esp. with mandatory signed commits) would obviate this issue completely.

But until that is the status quo for Portage (and reflected in the handbook etc.), I was suggesting something that could be integrated into the existing sync workflow with minimal cost / disruption.
_________________
Regards,

sakaki

[tholin]

It's good that someone is thinking about ways to improve portage sync. The insecure-by-default sync is probably gentoo's biggest wart.

I think gpg returns success even if the signing key has expired so you might want to check if the gpg key is still valid.

The hashfile contains the time the hash was generated but that info is not verified. verify_master_hash should make sure the date of the current hash is more recent than the previous hash to protect against downgrade attacks. Portage got its own timestamp file at /usr/portage/metadata/timestamp.x but I don't think portage use that for protecting against downgrades.

It looks like compute_master_hash reads every file in the portage tree every time, except some excluded directories. That might take 5sec with warm caches but on my system with cold caches it takes 45sec. emerge-webrsync only takes 39sec with cold caches and a 100Mbit connection. Since porthash will run right after rsync caches will be partially warm but most file content will not be cached.

Perhaps another way to do the hashing would be to use a merkle tree. The portage tree is already a tree so files could be treated like leafs and directories as non-leafs. That way changing a few files would only require hashing a subset of the full tree.
https://en.wikipedia.org/wiki/Merkle_tree