# RFC:  What's insecure about the way gentoo does rsync?

## klieber

From a security perspective, there are a number of things that make me cringe about the way Portage gets rsynced, ebuilds get distributed and source tarballs get downloaded.  I'd like to come up with a list of things that can be done to make the rsync'ing and source downloading process more secure.  Here's a preliminary list, along with descriptions.  Please add further suggestions using this same format as it will make my life a lot easier when it comes to consolidating it all.

ebuilds are not digitally signed -- there is no way to verify that an ebuild in the Portage tree came from a bona-fide Gentoo developer.solution -- have developers start digitally signing ebuilds and modify Portage to support automatic verification of digital signatures.

rsync mirror servers have rudimentary (IP-based) authentication --  if authentication was stronger, it would reduce the risk of man-in-the-middle/session hijacking attacks.

solution -- utilize rsync over ssh for the mirrors and then use key pairs for authentication.

Anyone can be an rsync mirror -- right now, the only requirements for becoming an rsync server are that you have a reasonably fast pipe.  Theoretically, someone could set up a legitimate rsync server, get added into the official Gentoo rsync round robin and then start distirbuting poisoned/trojaned ebuilds.solution -- same as #1 -- digitally sign ebuilds and verify signatures during the emerge process 

So, what do you think?  Did I leave anything out?  Are there gaping holes in my thought process?

--kurt

----------

## fusion

I can't think of anything right now, but I really think this is a good idea and should be worked on right away.

----------

## gabriel

just to echo who was mentioned in gentoo-user:

Letting pretty much anyone run a server and have portage pick one at random (or however it goes) doesn't even let you trust md5sum checks as the digest for files can be easily created.  There would have to be some sort of ebuild gpg signing (like the loki update tool has) or something to force a 'phone home' to confirm an md5sum or gpg key.  A lot of that depends on having the infrastructure to do it (read: big ass servers, big ass pipe).

----------

## phong

My understanding that md5 checksums are not all that cryptographically strong - they may not be adequate for protecting from trojaned tarballs.  Some sort of more robust digital signature on the distributed source would be a good idea.

----------

## masseya

RE:  rsync mirrors have rudimentary (IP-based) authentication

I'm assuming that the keys you are talking about here are gentoo developer signed keys and not ones that are signed at the rsync mirror level.  (i.e. Should each rsync server's authentication matter if all the packages are signed by a Gentoo verifiable key?)

----------

## rac

I'm with Tristam29 here, unless the point of the rsync mirror authentication is to preserve the priority access that the mirrors get: i.e. avoid people pretending to be mirrors to get faster updates.

As long as ebuilds are signed, and the md5 or sha1 or whatever digests of the source tarballs and accompanying patches are also signed, the danger from rogue rsync mirrors goes away.

----------

## epowers

Below I propose a solution to the Portage tree security issue. First, however, I'll make a few observations. 

1. If you can trust the data because of cryptographic signatures, you don't have to trust the mirror, the mirror admin, or the link between you and the mirror. A bad mirror admin, bad data on a mirror, or a man-in-the-middle attack will all result in invalid cryptographic signatures. 

2. The official rsync server can automatically sign everything in it's CVS checkout with a single official Gentoo key; the developers don't have to sign anything themselves. The developers connect to CVS over SSH (or at least they better, no admin in his right mind would trust pserver directly), so if it's in CVS, a developer put it there. The only people with CVS write access are the developers. 

3. Observation 2 depends on the link between the official rsync server and the CVS server being trustworthy, and on the security of both machines. 

Here is my solution: 

1. Add the file /usr/portage/checksums and its cryptographic signature /usr/portage/checksums.sig to the Portage tree. This file has three parts. 

a) A recursive directory listing of the portage tree, but only the first two levels. (It would look a lot like the output of "tree -dfi -L 2 /usr/portage".) After the name of each directory is the timestamp of the most recently modified file beneath it. 

b) The sha1sums of the handful of files in /usr/portage. 

c) A timestamp stating when this file was last updated. 

2. In each /usr/portage/X/Y directory, add a file checksums and its cryptographic signature checksums.sig to the Portage tree. This file contains the sha1sums of every file in or beneath that directory. (The contents would look a lot like the output of "cd /usr/portage/X/Y && sha1sum `find -not -type d`".) It also contains a timestamp stating when it was last updated. 

3) Scripts running on the official rsync server would update these additional files whenever it updates it's checkout from CVS. 

4) The official Gentoo public key should be available through some secure means, such as via HTTPS from www.gentoo.org. 

Here's my reasoning: 

It's important to be able to cryptographically verify the integrity of every single file in the Portage tree, not just the ebuilds. (Especially the patches in those "files" subdirectories!) 

However, signing every single file will take up a lot of disk space and is probably too computationally intensive for the official rsync server. 

Instead of signing every file, generate a file full of checksums and sign that. The checksums are smaller than a signature and faster to compute, and you don't loose any effective security. 

However, you can't have one big checksum file either since an rsync isn't atomic. Instead, have checksum files on a per-second-level-directory basis. (Plus, this way the server can use logic to regenerate only those checksum files that have changed.) 

If you have a checksum file on a per-second-level-directory basis, a rogue mirror admin could delete second-level directories from their mirror without anybody noticing. Rogue mirror admins could also intentionally refrain from updating certain second-level directories. (Suppose a remote security hole was discovered; doing this and logging every connection would give the rogue admin a list of potentially vulnerable targets.) To fight this, in the root of the portage tree include a cryptographically signed list of all the second-level directories and their checksum file timestamps. Also include timestamps in the second-level-directory checksum files. 

After all this, a rogue mirror admin could still simply stop rsyncing his mirror. So, "emerge sync" should check the timestamp in the root checksum file after rsyncing. If it is more than, say, 25 hours old, it should print a warning. 

If Portage did this, we could always tell with absolute certainty whether the tree we rsynced was unmodified and current. 

Note that /usr/portage/X/Y/checksum timestamps older than those listed in /usr/portage/checksum are a definite cause for concern, but newer timestamps are not. That is normal (because an rsync isn't atomic) and not dangerous. 

I think this method covers just about everything once you assume the official servers are secure and the developers are trusted. Comments?

----------

## rac

Thanks for posting this, epowers.  You clearly put a lot of thought into it.  There are three reasons I would prefer to have developers sign ebuilds instead (actually, if there were a digest for the ebuild in the digests file, the digests file is really the only one that needs to be signed): The main rsync server has to do no signing at all, so it reduces the load on this overburdened central resource

I think the information of who actually did what is valuable both to other developers and to users, and it's nice to have it in a signature rather than just relying on a changelog

I have worried since I started using Gentoo about single points of failure.  I think the day will come (in the not too distant future) where the single CVS repository is no longer tenable, and I want a signing solution that will gracefully continue to work with a decentralized distribution system.

----------

## mglauche

how about signing the ebuild's together with the matching md5-sum file by the developer who did submit/maintain the ebuild, then publich all public keys of the developers by some secure channel, and check the signatures before building the ebuilds.

----------

## klieber

 *gabriel wrote:*   

> There would have to be some sort of ebuild gpg signing (like the loki update tool has) or something to force a 'phone home' to confirm an md5sum or gpg key.  A lot of that depends on having the infrastructure to do it (read: big ass servers, big ass pipe).

 

If the developer's keys, along with a master Gentoo key, were installed as part of the default Gentoo install, you wouldn't have to have any sort of 'phone home' feature whatsoever.  All verification could be done locally as part of the emerge process.

rac suggested this a while back and I know some of the developers have kicked the idea around as well.  This is also what Debian does

--kurt

----------

## masseya

rac --

I agree with you as far as making sure there isn't a single point of failure.  However, as epowers pointed out, a rouge rsync server admin could theoretically not update a particular ebuild that has a security hole.  Then they could keep a log of everyone who tried to update recently who checked that particular program to see if there was a new version.  Viola, a list of people to hack as well as the exact exploit to use.  If ebuilds are signed individually, the old one could still be signed.  Essentially, this boils down to making sure that you can trust that the ebuilds on the rsync server are relatively up to date.  Merely signing the packages, although it scales well, does not do this.  How would you propose to do this without requiring the rsync servers to have some security/authentication?  I have to confess I wouldn't have thought of that particular ploy on my own.  Thanks for posting epowers!

----------

## klieber

 *Tristam29 wrote:*   

> a rouge rsync server admin could theoretically not update a particular ebuild that has a security hole.
> 
> ...
> 
> How would you propose to do this without requiring the rsync servers to have some security/authentication?

 

The master rsync server(s) could grep together a list of ebuild signatures into a separate file which would be distributed as part of the Portage tree.  This file would, of course, be signed and timestamped.

Then, as part of the emerge process, the master signature file would be checked both for timeliness as well as authenticity.  If the timestamp is more than a few hours old, a warning gets displayed and (optionally) the ebuild process is halted.  Assuming it passes both checks, the ebuild signature would first be authenticated and then be validated against the master list of signatures to ensure it's the most up-to-date version.

The major problem  I can see with this is dealing with multiple time zones.    However, I'm assuming Portage could be modified to look at /etc/localtime and intelligently interpret that.

--kurt

----------

## epowers

rac, you're right about the load on the Gentoo servers.

I still think having the developers sign the ebuilds directly is overkill, however. If the CVS server is secure, it's revision history is trustworthy. So there is an implicit (automatic) record of not only who has signed off on the ebuild, but also which changes they specifically signed off on. The detail is marginally greater than that given just by the signatures, and most importantly, the devels can keep doing things exactly the same way they do already. The changes are transparent to them.

You're right that this doesn't scale well, but then, neither does CVS. We wouldn't run into the scalability problems of this method until we are ready to switch away from CVS or even a CVS-like system (Subversion has the same limitation). I think that's far enough in the future that we can be a little short-sighted in our security implementation.

----------

## klieber

 *epowers wrote:*   

> I still think having the developers sign the ebuilds directly is overkill, however. If the CVS server is secure, it's revision history is trustworthy.

 

Actually, I think it's a good idea.  What happens if a developer's ssh key gets compromised?  With one master key, there's no easy way to go in and revoke any/all ebuilds associated with that developer.  However, if the developer uses their own gpg key, you simply have the master key revoke its trust of that developer and Portage will immediately start refusing to install those ebuilds.

Additionally, if you assume that the master key is *not* held on the CVS server, but rather somewhere else (drobbin's personal machine, etc.) and you also assume that adding new dev keys to the Gentoo keyring is done manually, then even if the CVS server gets hacked, you don't have to worry about the integrity of the master Portage tree because it's impossible for a rogue user to add themselves to the Gentoo keyring or modify any ebuilds undetected.  Whereas with your proposal, if the CVS server is compromised, the cracker can modify ebuilds and cover his tracks by modifying the CVS logs.  

--kurt

----------

## epowers

 *klieber wrote:*   

> Assuming it passes both checks, the ebuild signature would first be authenticated and then be validated against the master list of signatures to ensure it's the most up-to-date version.
> 
> The major problem  I can see with this is dealing with multiple time zones.

 

You don't have to actually validate against a master list to ensure it's the most up-to-date version.

The only way for the master signature file to be current and for it's information to match is for all the subdirectory signature files to be current. Since it's easy to guarentee that the master signature file's timestamp is updated frequently, you don't have phone home at all once you have the Gentoo public key.

As for timezones, you'd of course want to ensure that the timestamps in Portage were in UTC. It's really easy to aquire the UTC version of the localtime, so the client end isn't a problem (unless the system clock is shot, but then you could always have an option to disable the tree security checks).

----------

## epowers

 *klieber wrote:*   

> What happens if a developer's ssh key gets compromised?  With one master key, there's no easy way to go in and revoke any/all ebuilds associated with that developer.

 

Well, if his ssh key is compromised, his home machine probably is too--and therefore his private key.

Actually, there's a very easy way to revoke any ebuilds associated with that developer. Using CVS, roll back every single file in portage to before the rogue developer modified it. Then you're done--the master signature file's timestamp will age and automatically "revoke" old ebuilds.

It's not as pretty, no, but it's more practical I think, especially since users would essentially have to sync again to notice the revoked keys anyway.

You are of course right about the threat of someone hacking the CVS server itself. However, there's that famous adage about computer security. The only way to make a computer completely secure is to make it unusable.

I think minimizing the amount of work the devels must do is very important. So important that the hacking threat is an acceptible one; developer productivity is more important.

----------

## klieber

 *epowers wrote:*   

> Well, if his ssh key is compromised, his home machine probably is too--and therefore his private key.

 

Right, which is why you then have the master key revoke all trust for that key.

 *epowers wrote:*   

> Actually, there's a very easy way to revoke any ebuilds associated with that developer. Using CVS, roll back every single file in portage to before the rogue developer modified it. Then you're done--the master signature file's timestamp will age and automatically "revoke" old ebuilds.

 

What ensures the integrity of the CVS log files?  Also, how do you know exactly when the developer's machine became compromised so you know how far to roll back CVS?

[EDIT]  As I'm reading your suggestion again, you say "every single file in portage".  Do you mean *every single file*???  Or all files that the developer touched?  If you mean the former, what do you do if drobbins' ssh key gets compromised since he's been with Gentoo since its inception?  Start from scratch?

If you mean the latter, then my question about ensuring the integrity of the CVS log files becomes that much more important.

[/EDIT]

 *epowers wrote:*   

> It's not as pretty, no, but it's more practical I think, especially since users would essentially have to sync again to notice the revoked keys anyway.

 

By using unique developer keys, rather than one master key, you limit the amount of damage that can happen by one developer's machine getting compromised.

--kurt

----------

## epowers

 *klieber wrote:*   

> Right, which is why you then have the master key revoke all trust for that key.

 

Duh, yeah. Sorry.

 *klieber wrote:*   

> What ensures the integrity of the CVS log files?  Also, how do you know exactly when the developer's machine became compromised so you know how far to roll back CVS?

 

The integrity of the CVS log files is ensured by the security of the CVS machine itself. If things are set up correctly, the log files can't be manually edited by the developers, only the CVS server admin. Of course, if the CVS server admin can't be trusted, all bets are off anyway.

You roll back every file touched by the developer to some point in time before he touched it. That's about the only thing you can do until you audit every file the developer touched.

If drobbins happens to be the one compromised, you would pretty much have to roll back to the beginning, unless he knew he was hacked after a certain date. There's not much else you could do, besides doing nothing.

 *klieber wrote:*   

> By using unique developer keys, rather than one master key, you limit the amount of damage that can happen by one developer's machine getting compromised.

 

Oh, don't get me wrong. I agree totally that having per-developer keys is a technically superior system, from a security standpoint. I just think there are practical disadvantages to doing things that way, and enough of them to make the sacrifice worthwhile.

1. CVS won't play nicely with the signatures (the RCS files would be huge and slow) so you'd need two systems, a CVS server to commit the data and some other kind of server to commit the signatures.

2. Developers have to do more. If we proposed a per-developer key system, their workload would greatly increase under it. So they'd probably fight it, and the problem would go unresolved. A less technologically secure, put still sufficiently secure, system like I described would afford us about as much protection as we can realistically expect while being totally transparent to the developers.

-----

Besides, there's no reason we can't solve the problem in two pieces.

Design one nice, simple, small, and fast system like mine to guarentee that the rsync mirrors are serving current, unchanged Portage trees.

Then, design a second, more complicated system to guarentee that the official Portage tree is trustworthy.

----------

## klieber

 *epowers wrote:*   

> 1. CVS won't play nicely with the signatures (the RCS files would be huge and slow) so you'd need two systems, a CVS server to commit the data and some other kind of server to commit the signatures.

 

Sorry -- you lost me here. Why would signing the ebuilds dramatically increase their size? (I'm not a CVS guy)  

 *epowers wrote:*   

> 2. Developers have to do more. If we proposed a per-developer key system, their workload would greatly increase under it. So they'd probably fight it, and the problem would go unresolved. A less technologically secure, put still sufficiently secure, system like I described would afford us about as much protection as we can realistically expect while being totally transparent to the developers.

 

Actually, most of the developers are on board with signed ebuilds -- it's been discussed fairly extensively on -core and #gentoo-dev.  It probably won't be as hard to sell to the developers as you might think.

 *epowers wrote:*   

> Besides, there's no reason we can't solve the problem in two pieces. 

 

Agreed, but I think that signed ebuilds, if implemented correctly, can solve  it all by itself without having to break it out into two pieces.

--kurt

----------

## epowers

 *klieber wrote:*   

> Sorry -- you lost me here. Why would signing the ebuilds dramatically increase their size? (I'm not a CVS guy)

 

The problem is that RCS isn't very good at several of the things it's used for. Certain CVS operations cause the RCS files to grow exponentially and become much slower to work with.

However, on second thought, this isn't the problem I thought it was. The size would grow linearly with the number of commits made, as long as nobody ever created a CVS branch in the repository. Presumably this never happens.

 *klieber wrote:*   

> Actually, most of the developers are on board with signed ebuilds -- it's been discussed fairly extensively on -core and #gentoo-dev.  It probably won't be as hard to sell to the developers as you might think.

 

I would have said that's great earlier today, but during the boring four hour drive I just took I thought of something.

The only signature on an ebuild is going to be by the person who most recently modified it, because each modification breaks all the old signatures.

If a poisoned ebuild is found, the person who most recently modified the ebuild is probably not the person who poisoned it. Most of the files in Portage are maintained by several people, and there are a few developers who go through the tree making stylistic changes.

Therefore you won't be able to revoke a developer's key and have Portage refuse to install any of the ebuilds he's touched, because Portage won't know he touched a file if someone touched it after he did.

And you can't just keep a list of the signatures that used to be valid for a file, because there's no way to determine whether the now-invalid signatures were ever valid without knowing what the old versions looked like. You'd have to include the RCS files from CVS in the tree; Portage's size would explode. emerge would become noticably slower too, because it would have to check all the signatures, and that would require extracting lots of old versions from the RCS files.

The only way to retain that information but keep the keys distributed would be to, for each file in Portage, have another file listing who had ever edited it. Then, you'd have to force every developer named in that file to resign it whenever the file changed. It would be an organizational nightmare, and you'd still loose the cryptographically signed detail about who made what changes.

It's probably possible to have per-developer signed ebuilds, but we're going to have to put a lot of thought into the system.

If the developers are on board about per-developer signed ebuilds, we should definitely make that effort, but I still suspect breaking the problem into pieces is what we'll have to do in the end. The problem is too large, we'll miss things if we try to tackle the whole thing at once.

----------

## klieber

 *epowers wrote:*   

> Therefore you won't be able to revoke a developer's key and have Portage refuse to install any of the ebuilds he's touched, because Portage won't know he touched a file if someone touched it after he did.

 

Good point, but one that I think we can still work around.   If you think about it, a poisoned ebuild is a pretty Big Deal and, with a well-thought out system, it shouldn't happen that often.  So, with that in mind, if it *does* happen, I don't think it's unreasonable to revoke the trust of multiple keys if an ebuild has been touched by multiple developers since the time it was poisoned.  

Using this method, if the ebuild for foo gets poisoned and developer A was the one who poisoned it (inadvertantly or otherwise) but developer B made a stylistic change to the formatting of the ebuild, post-poisoning, then revoke the key trust of developer A and B.  Problem solved.

Yes, this creates something of a hassle for poor developer B, but at the same time, poisoned ebuilds should not be a daily occurance, so theoretically, some extra hassle is acceptable in this case.

--kurt

----------

## masseya

 *klieber wrote:*   

> Yes, this creates something of a hassle for poor developer B, but at the same time, poisoned ebuilds should not be a daily occurance, so theoretically, some extra hassle is acceptable in this case.

 

It wouldn't be security without some kind of a hassle.   :Smile:   I'm sure the developers understand this and are willing to take this risk.  Even still, I don't think this is all that much of a hassle.  I'm sure that Developer B would have some records of the valid changes that he's made to a file.  At that point it's not hard to copy, paste and touch-up.  Of course there's the worst case scenario where Developer A's poisoning isn't found until quite a few important changes are made.  This is an unaviodable scenario and planning to prevent it is bad policy.  We need a security system that fails gracefully, because it will fail regardless of how well we plan.

----------

## epowers

 *klieber wrote:*   

> So, with that in mind, if it *does* happen, I don't think it's unreasonable to revoke the trust of multiple keys if an ebuild has been touched by multiple developers since the time it was poisoned.

 

I dunno, I balk at the idea of revoking more keys than are absolutely necessary. The additional keys you'd need to revoke would be people like blizzy and vapier who seem to touch just about everything. 50% of Portage just disappearing rather than rolling back into the past is a pretty big deal.

 *klieber wrote:*   

> revoke the key trust of developer A and B.  Problem solved.

 

Well.... How do you know who the people are that have modified a file, and when they modified it? You'd have to get it out of the CVS history, but the whole point of this was that you shouldn't trust that information. Archiving the old signatures doesn't really help either, because a rogue developer could edit the RCS files in CVS by hand, add something like a single space at the end of a line, and suddenly it would look as if someone was trying to incriminate him, because his signature wouldn't match.

I think everything boils down to trusting CVS, and if we have to do that, we don't gain anything from per-developer keys without some serious work. Which I still think we ought to look into, my point is just that it won't just work out of the box.

 *Tristam29 wrote:*   

> This is an unaviodable scenario and planning to prevent it is bad policy. We need a security system that fails gracefully, because it will fail regardless of how well we plan.

 

I totally agree. I think we can design something that fails much more gracefully than revoking the keys of everybody who's touched a file since it was poisoned. I'm going to think about that....

----------

## Xor

well, I found a lot of good stuff... but a lot of "changemanagement" so please forgive me if I repeat something. I originally found this thread because I was on the search if not someone came allready up with the idea to use sha1 instead of md5 for the checksums....

the need for a digest is still needed I assume, as we can't controll the tar.gz on a legazy server (see ssh desaster and other trojans) with that tool such attacks are really good prevented - as long as the developer didn't use a trojaned version.

for the purpose of ebuild verification, you don't need to sign them you case have to make portage aware, that you trust a certain key(s) (it has to be extendable to local keys! so folks at home can use the same shema)

regarding the problem with the "cvs touching" problem. of course cvs dosn't know gpg (I think) but to make it valid you have to sign the ebuild and while doing that you have to verify the original signature - and as long as revoking works you are fine.

but the revokation (blacklist) or the opposite (whitelist) is then a very essential part of gentoo, and people laid out that they miss a certain possibility to mark certain updates vital (ssh updates, ssl updates or in this case key updates)

just for the record, I don't think that the server should sign the ebuild, because he is not the source of the data - despite of the load it causes. Only the developer can garantee the correctness of the content.

to make it short:

replace mf5 by sha for tarball sigs

sign the sigs and the ebuild by the developers gpg-key

maintain a database of good keys which is distributed through a key package

make portage aware of the feature, it should not handle any files with an invalid signature (don't even start to download the file - nothing)

I don't know if deelopers use the "cvs" tools to commit changes, but signing of the ebuild should only be possible if the signature on the old file was right - or maybe the event of a compromissed key should be blessed by a most trusted entity. like: ok the key of this package is compromised, some skilled ebuilder revised the ebuild, found it good and therefore the signature is overruled by a special key, for here on normal signature may sign the ebuild.

just some wild ideas - if somebody dosn't understand I'll write in in german, where I can express myself better  :Wink: 

----------

## epowers

 *Xor wrote:*   

> regarding the problem with the "cvs touching" problem. of course cvs dosn't know gpg (I think) but to make it valid you have to sign the ebuild and while doing that you have to verify the original signature - and as long as revoking works you are fine.

 

CVS is a rather large problem, actually. Just about every file in Portage uses CVS keyword expansion in one or more places ("$Version: $" at minimum). These keywords will defeat the obvious methods for developers to sign their files. There are other problems it causes, of course. If you read some of my earlier comments, I note that Gentoo's development and distribution model has a natural "center of trust" located at the CVS server.

In other words, all the proposed methods of solving the problem explicitly or implicitly depend on everyone trusting the CVS server. If the CVS server is hacked, the hacker can defeat the signatures by rendering them useless (even without aquiring anybody's private key; see the above posts).

This is why I advocate having the server sign the ebuilds. Since there's no theoretical advantage to anyone/anything else signing the ebuilds (the CVS server is ultimately trusted), why bother? Especially since anything else is orders of magnitude more complicated.

 *Xor wrote:*   

> sign the sigs and the ebuild by the developers gpg-key
> 
> maintain a database of good keys which is distributed through a key package

 

Even if a distributed signature system were possible (my previous posts explain how it is probably theoretically impossible), just signing the ebuilds is not enough.

Consider the following scenario. A malicious person sets up an rsync mirror and gets added to the round-robin DNS. (This is quite probable; Gentoo currently doesn't screen mirror applicants IIRC.) The malicious person waits until a GLSA for a popular package is released, then tweaks his mirror to contain only the old ebuilds for the vulnerable version. Note that these ebuilds have valid signatures. The malicious person then logs the IP of anyone rsyncing from his mirror. He now has a list of people who still have the old, vulnerable version, and can use it as a checklist of machines to hack.

Or consider another scenario. A malicious person does the exact same thing, but allows a large number of ebuilds to become stale. People rsyncing from his mirror notice lots of bugs which the newer versions fix, and the mailing lists get flooded with posts about issues that are already resolved. Gentoo's mailing lists become less useful, and development slows.

The point is that an authentic portage tree is insufficient. An authentic but stale tree can be just as dangerous.

----------

## klieber

 *epowers wrote:*   

> The point is that an authentic portage tree is insufficient. An authentic but stale tree can be just as dangerous.

 

You're talking about two different problems with two different solutions.  On one hand, you (meaning all of us) want to ensure the integrity of the ebuilds being downloaded.  Whether or not they're stale, you still want to ensure they haven't been modified in any way since the developer originally created it.

On the other hand, you want to ensure the various rsync mirrors contain timely information.  That is a separate issue, IMO and one that is best handled with a separate solution.  Probably something server-side run by the master rsync server.  It could generate some sort of signed hash based on the current portage tree and check each rsync server to verify the hash (and signature) is the same.

BTW, your suggestion of having the CVS server sign ebuilds instead of the developers doesn't mitigate the risk of a stale portage tree at all.

--kurt

----------

## klieber

 *Xor wrote:*   

> replace mf5 by sha for tarball sigs

 

Why?

--kurt

----------

## Xor

 *Quote:*   

> CVS is a rather large problem, actually. Just about every file in Portage uses CVS keyword expansion in one or more places ("$Version: $" at minimum). These keywords will defeat the obvious methods for developers to sign their files. 

 

ok, then tell me how debian solved the problem? I guess it's a question of design....

 *Quote:*   

> Consider the following scenario. A malicious person sets up an rsync mirror and gets added to the round-robin DNS. (This is quite probable; Gentoo currently doesn't screen mirror applicants IIRC.) The malicious person waits until a GLSA for a popular package is released, then tweaks his mirror to contain only the old ebuilds for the vulnerable version. Note that these ebuilds have valid signatures. The malicious person then logs the IP of anyone rsyncing from his mirror. He now has a list of people who still have the old, vulnerable version, and can use it as a checklist of machines to hack.
> 
> Or consider another scenario. A malicious person does the exact same thing, but allows a large number of ebuilds to become stale. People rsyncing from his mirror notice lots of bugs which the newer versions fix, and the mailing lists get flooded with posts about issues that are already resolved. Gentoo's mailing lists become less useful, and development slows. 

 

both problems have the same source: how can you tell whether a mirror is in sync or not - to do a simple (at possible stupid) attemp to solve this: make a signed list of packages - if a mirror fails to deliver the same list it is not in sync.... of course you would have to download the shasum (can we please abandon md5?!) of the list from the master server -which prevents outdated packages.

but I am agains signing on the server:

as only the developer can garantee of the content of the date he publishes - it makes no sense that a "man in the middle" signes for him, as whether the develper norI can be sure the data hadn't been altered on the server - and as the server does the signing all signing becomes void as soon as an intrusion would be detected - and history (ssh, tcpdump) teaches us - it is possible - depending on the sysadmin it may take minutes or month to discover an intrusion.

so please, when (not if - I see it as a must) a secure package delivery is implemented, please make it sound, make it trustwothy - put the trust in the one who builds the packages and not in a single-point-of-trust-automatic-generated-signature-model.

And most of all - which all of the dists I saw yet fail - use that feature!

regards

xor

----------

## klieber

 *Xor wrote:*   

> (can we please abandon md5?!)

 

You still haven't articulated why we need to abandon md5.  md5 uses 128 bit encryption and sha1 uses 160 bit.  Factoring in the birthday paradox problem reduces the effective encryption to 64 and 80 bits, respectively.  Sure, 80 bits is stronger than 64 bits, but it still took distributed.net 1700+ days to crack a 64 bit RC5 key.  Granted, rc5 and md5 are different, but 64 bits is 2^64 any way you look at it.  

So, the question to you is; why do we need to abandon md5?

--kurt

[EDIT]  I use the term "encryption" in relation to md5 hashing, which is technically incorrect.  "Message digest" would have been more appropriate.[/EDIT]

----------

## epowers

 *klieber wrote:*   

> You still haven't articulated why we need to abandon md5.

 

I Am Not A Cryptanalyst, but a little research revealed the following.

Consider this page on rsasecurity.com:

 *Quote:*   

> More recent work by Dobbertin has extended the techniques used so effectively in the analysis of MD4 to find collisions for the compression function of MD5 [DB96b]. While stopping short of providing collisions for the hash function in its entirety this is clearly a significant step.

 

The Dobbertin paper referred to can be found here. It mentions 10 hours of computer time being needed for Dobbertin's result.

Basically, while cryptologist's haven't actually managed to defeat MD5 yet, they've made enough theoretical progress that the confidence of cryptologists in the MD5 algorithm is waning.

An example of what apparently could become possible when, or if, the cryptologists succeed in defeating MD5:

1) Compute the MD5 hash of the file to be attacked.

2) Compute a block of message text which has the same MD5 hash and a few other properties.

3) If finding such a block was possible, prepend whatever data you want to it.

4) The result of step 3 has the same hash as the original file.

Scary stuff if the breakthroughs are ever made.

----------

## klieber

 *epowers wrote:*   

> here. It mentions 10 hours of computer time being needed for Dobbertin's result.
> 
> Basically, while cryptologist's haven't actually managed to defeat MD5 yet, they've made enough theoretical progress that the confidence of cryptologists in the MD5 algorithm is waning.

 

I hadn't seen this paper before -- thanks for pointing it out.  I posted a question regarding its vailidity on the CISSP list and most of the responses seemed to revolve around the fact that this paper is going on 7 years old and md5 hasn't fallen yet.

Anyway, I imagine given a fresh slate and a choice between md5 and sha1, one might choose sha1.  However, there certainly does not appear to be a need to "abandon" md5 as a hashing algorithm.

As with all things related to security, the level of protection you require depends directly on the type of data being protected.

--kurt

----------

## Suicidal

Would the ebuilds in the PORTDIR_OVERLAY be excluded for being signed since they are not official?

----------

