# Default Gentoo settings too weak in security?

## Roman Zilka

I've been thinking about the trustworthiness of everything that I download from the Internet, install and run. The thing that got me started was the realization that by default:

 * 'emerge --sync' and 'webrsync' use no authentication, i.e., I'm downloading something from somewhere;

 * Manifests are signed, but the signature is not verified by emerge, i.e., the distfile/ebuild checksums in them can be arbitrary; I'm installing something from somewhere.

The chances of anything bad happening are tiny, but not zero. Yes, one can set their system up to make GPG verifications and stuff. What I'm thinking about is that these measures might as well be a part of the default Gentoo setup. Please add your comments on the topic before I try to open an official bug.

I propose these specific changes:

[1] Under *.gentoo.org, access to the mirrorlist, the handbook and all downloads limited to https. According to bug #470054 we will soon have https; the point is that it must be enforced at least for the aforementioned locations.

[2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded. Of course, the user can still skip this.

[3] Stage3 should come pre-configured for GPG-enabled webrsync by default and the handbook should recommend sticking to this route. The added difficulty is basically zero for those who'd already downloaded the public key in the earlier installation phases, and minimal for others (copying a few commands from the handbook).

[4] (alternative for [3]) Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added.

----------

## Hu

Files can be published over http, if you have a secure way of validating the file once it is received.  For example, fetching the digest over https from a trusted host and validating the digest provides integrity for the received file.

GPG-enabled webrsync is a good security measure, but comes at a cost.  The entire tree is fetched every time and snapshots are created only once a day.  Therefore, users who want the absolute latest cannot use this.  Also, users on restrictive bandwidth plans may find the repeated full download expensive compared to their daily/weekly rsync.

----------

## mv

See glep 58

It is a shame that there are no efforts to implement it   :Wink: 

----------

## Roman Zilka

OK, reformulating items 1 and 3.

[1] Under *.gentoo.org, access to the mirrorlist and the handbook limited to https. According to bug #470054 we will soon have https; the point is that it must be enforced at least for these two locations.

[2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded. Of course, the user can still skip this. 

[3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.

[4] (alternative for [3]) Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added.

----------

## Roman Zilka

 *mv wrote:*   

> See glep 58
> 
> It is a shame that there are no efforts to implement it  

 

So there is one after all... Let's see what it's got.

----------

## Roman Zilka

OK, the GLEP covers item [4]. The rest is on the table.

[1] Under *.gentoo.org, access to the mirrorlist and the handbook limited to https. According to bug #470054 we will soon have https; the point is that it must be enforced at least for these two locations.

[2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded.

[3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.

[4] (alternative for [3]) GLEP 58: Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added.

----------

## user

I using webrsync with GPG check,

but a deep packet inspection should *not* disclose that I use a mirror host service for gentoo fun.

Using an "unsuspicious" mirror host via HTTPS connection can deal with it.

Lets check which mirror host supports out-of-the-box HTTPS connection:

```
# wget -qO - http://www.gentoo.org/main/en/mirrors3.xml | sed -n 's|.*http://\(.*\)<.*|https://\1|p' | sort -u | xargs wget -nv -O /dev/null -t 1 -T 1 2>&1 | grep URL:https

URL:https://ftp.rnl.ist.utl.pt/pub/gentoo/gentoo-distfiles/ [1037/1037] -> "/dev/null" [1]

URL:https://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ [1006/1006] -> "/dev/null" [1]

URL:https://gentoo.mirror.pw.edu.pl/ [110/110] -> "/dev/null" [1]
```

Only three mirror hosts supports HTTPS protocol.

One of them is disqualified, because we would leak gentoo usage via DNS query.

Only two, less choice currently.

----------

## phajdan.jr

 *Roman Zilka wrote:*   

> [2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded.

 

Feel free to file a bug for handbook changes. With Sven (swift) being around, this can hopefully be dealt with... swiftly.   :Wink: 

 *Roman Zilka wrote:*   

> [3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.
> 
> [4] (alternative for [3]) GLEP 58: Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added.

 

I think the hope is that portage's migration to git will introduce GPG-signed commits.

----------

## Bones McCracker

 *phajdan.jr wrote:*   

> this can hopefully be dealt with... swiftly.

 

 :Laughing: 

----------

## mv

 *phajdan.jr wrote:*   

> I think the hope is that portage's migration to git will introduce GPG-signed commits.

 

But AFAIK this should not involve users (in contrast to developers) who have no need for the full git history: For them rsync should still be the preferred option.

In fact, I would not want to store hundreds of MB of unnecessary history on all gentoo systems when I can keep the currrent portage tree in a 60MB squash filesystem. Unfortunately, in contrast to other VCS like bzr, git is very poor when it comes for thin/partial checkouts of data or history: AFAIK either it requires lot of storage or lot of transferred data. But on the other hand, I would want to get some kind of "signing" of the tree anyway...

----------

## Hypnos

A shallow git clone would have the same ease-of-use as rsync, as long the master repo is never rewound.

----------

## mv

 *Hypnos wrote:*   

> A shallow git clone would have the same ease-of-use as rsync, as long the master repo is never rewound.

 

It would really only transfer the modified data by an accretive algorithm? I would expect it has to transfer all data if practically nothing is stored in .git, but I may be wrong.

----------

## Roman Zilka

 *phajdan.jr wrote:*   

>  *Roman Zilka wrote:*   [2] The handbook instructs the user to verify the GPG signature on installation media (chap. 2), but fails to do so with the stage3 (chap. 5). The verification is required for gentoo.org to delegate trust to the mirror from which stage3 had been downloaded. 
> 
> Feel free to file a bug for handbook changes. With Sven (swift) being around, this can hopefully be dealt with... swiftly.   

 

I filed this as #470750.

 *phajdan.jr wrote:*   

>  *Roman Zilka wrote:*   [3] Stage3 should come pre-configured for GPG-enabled webrsync. In chap. 6 the handbook should give instructions to make a GPG-enabled webrsync and the two unauthenticated sync's. 'Emerge --sync' should be able to authenticate rsync mirrors. SSH tunneling is a quick thought.
> 
> [4] (alternative for [3]) GLEP 58: Emerge should use GPG to check the integrity of everything in the tree it even opens. Manifests are already signed, but the signature is not checked (not by default, anyway). Eclasses, metadata et al. don't even have Manifests. These would have to be added. 
> 
> I think the hope is that portage's migration to git will introduce GPG-signed commits.

 

How far away is the transition? Can that be told?

----------

## _______0

I've always wondered why isn't https default from the get go.

----------

## phajdan.jr

 *Roman Zilka wrote:*   

> How far away is the transition? Can that be told?

 

Not sure if this is adding much: there is progress, but sort of slow. Also, I have an impression that as things are progressing, a bit more issues come up that add to the TODO list before transition can be fully made.

 *_______0 wrote:*   

> I've always wondered why isn't https default from the get go.

 

Good question, and I think it's totally reasonable. Feel free to file a bug (there might already be one).

----------

## Bones McCracker

Why isn't the gentoo CA certificate (the one used to sign the bugzilla cert, for example) distributed as part of our ssl ca cert package?

----------

## 666threesixes666

i was thinking about this myself, from a completely different angle.  like an rsync that verifies data of other rsync mirrors, white lists the mirror, and hands off to locked down trusted local mirror.  like remote mirror has a checksum that must match the master servers checksum in case of mirror corruption, accidental or intentional.  i was also thinking about a "locking" file system that would trigger updates of checksums.  im just dreaming though, i have no skills to implement any of that, or knowledge if any of its already been done.  i prefer the webrsync, its easier.  im talking about like a wan clustering protocol, like drbd that when i hit gentoo.org it doesnt go to some server in alaska, but redirects me to the local mirror of the website in chicago.

----------

## Genone

TBH, the truth is that the design of the ebuild system is pretty bad to secure properly. This is due to the large number of different inter-dependent components, the direct exposure of users to changes and the lack of real containers. Add on top of that the lack of a strong government body in Gentoo, the rather anarchic development model (everybody can touch almost everything) and the poor GPG interfaces in the past and you may see why this topic has been stalled for years (not accounting "idealistic" debates over WoT vs. central signing authority or different attack vector scenarios).

Note I'm not saying the above issues are bad in general, just that they are counter-productive for a secure distribution system.

----------

