
Man-in-the-middle vulnerability on Gentoo sync and emerge - contingencies
https://bugs.gentoo.org/show_bug.cgi?id=597804
======
hannob
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](https://github.com/gentoo-
mirror/gentoo) which is a copy of the portage tree with pregenerated metadata.

~~~
zx2c4
The official source for git-over-https is:
[https://anongit.gentoo.org/git/repo/gentoo.git](https://anongit.gentoo.org/git/repo/gentoo.git)

~~~
TheDong
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.

------
jlgaddis
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](https://bugs.gentoo.org/show_bug.cgi?id=597800)

~~~
hannob
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.

------
0xmohit
Looks like this is in the process of getting fixed:

[https://bugs.gentoo.org/show_bug.cgi?id=597918](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...](https://gitweb.gentoo.org/proj/portage.git/commit/?id=98c250cceaf380d6dbeacac90482a5d1956dcb80)

~~~
TheDong
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.

------
0xmohit
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](https://bugs.gentoo.org/show_bug.cgi?id=597800)

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

~~~
jsprogrammer
The first comment linked to it[0]?

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

