Man-in-the-middle vulnerability on Gentoo sync and emerge | Hacker News Reader

Man-in-the-middle vulnerability on Gentoo sync and emerge

bugs.gentoo.org

90 pointscontingencies18 comments

As a long time gentoo dev I am happy that this gets more attention. Although this is an open secret and completely obvious. Gentoo's rsync-based system was always insecure. There have been multiple attempts to implement some kind of package signing, but it never made it to deployment.

A workaround right now is to use git-based sync over https. You can sync from https://github.com/gentoo-mirror/gentoo which is a copy of the portage tree with pregenerated metadata.

Hehe. I discovered this after our last discussion on HN, so really it's your doing. If you have handbook edit rights fixing that would be a good temporary measure... I've made some suggestions for revision: https://wiki.gentoo.org/wiki/Handbook_Talk:AMD64/Installatio...

I don't think the github-solution will make it into the official handbook. People want to have everything on Gentoo-owned infrastructure, which I can understand.

I think the github thing is just a python GPG wrapper library that gkeys uses (and was written for that purpose), whereas the gkeys tool itself is already on Gentoo-owned infrastructure.

Who is it run by? It's not under https://github.com/gentoo and the gentoo-mirror org doesn't have any "public members" ... I'd be more concerned with trusting this, than my ISP or OSU OSL MITM-ing me.

That aside, wouldn't it make sense to have the generated metadata in a separate repository? Sync the latest metadata, then check out the corresponding revision from the actual gentoo git repo.

The official source for git-over-https is: https://anongit.gentoo.org/git/repo/gentoo.git

Unlike rsync/webrsync/above repo, it doesn't have pre-generated metadata, which makes things painful

It's dangerous to recommend that instead of the github mirror because the gentoo.org git server is not made to scale to the number of users of gentoo.

That's the whole reason the rsync infrastructure exists in the first place.

Calculate Linux, a Gentoo-variant, already syncs over git, and is therefore immune to this issue.

I don't know Calculate Linux, but this indicates that they use the git://-protocol: http://www.calculate-linux.ru/blogs/en/320/show

That is just as insecure as rsync. You need to use https in order to protect data. (Appart from that it seems calculate linux doesn't even have a webpage over https...)

Funtoo as well, but the issue is that (at least for Funtoo), upstream that feeds the git has to be untampered with as well, which in this case is (you guessed it) Gentoo.

This bug (#597804) links to bug #597800 [0] titled "emerge-webrsync: Downloads .gpgsig by default, but doesn't verify it."

That's where the details are (and probably where this submission should point).

[0]: https://bugs.gentoo.org/show_bug.cgi?id=597800

Please note that this is only related to the webrsync-method. While securing that would be good, it's not the default. So even if we had a secure emerge-webrsync-feature it'd still leave most users vulnerable.

Looks like this is in the process of getting fixed:

https://bugs.gentoo.org/show_bug.cgi?id=597918

The change is in the master:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=98c250...

Those only refer to `emerge-webrsync`. That tool is typically used exactly once the first time a user installs gentoo. Every subsequent `emerge --sync` does not use that codepath, and so still needs a separate fix.

Another bug report [0] contains more details:

  This is dangerous as it is insecure default behavior. There may
  be an argument (poor) for keeping insecure default
  behavior. However, it is also doubly dangerous because it may
  imply to the user that the operation has been cryptographically
  verified when in fact it has not.

  Reproducible: Always

  Steps to Reproduce:
  1. emerge-webrsync
  2. "Fetching file portage-20161021.tar.xz.gpgsig ..."
  Actual Results:  
  User things "cool, it's verified"... but it's not verified, and
  no warning is shown to this effect.

  Expected Results:
  All downloads are cryptographically verified or, failing that,
  a big (preferably red, flashing) SCARY WARNING is shown.

  Probably it should whinge immediately and require the addition
  of an --insecure command line flag.

[0] https://bugs.gentoo.org/show_bug.cgi?id=597800

Is there an actual bug report somewhere or just a headline with some comments?

I'm not saying you have to educate from first principles, but sure would be nice to include the use case, expected behavior, estimate on how widespread the effect, steps to reproduce,... This is basically a tweet.

The first comment linked to it[0]?

[0] https://bugs.gentoo.org/show_bug.cgi?id=597800

Reply on news.ycombinator.com