Summary: | Portage improvement thorugh binary packages p2p sharing. | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Stefano Peluchetti <pelux> |
Component: | Core - External Interaction | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | Arsen.Shnurkov, dbaird, fava, graaff |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 8468 | ||
Bug Blocks: |
Description
Stefano Peluchetti
2003-06-30 03:11:55 UTC
So what happens if a package is incorrectly compiled, where the compile succeeds but the package does not work? Is there some way to test before setting it up for sharing? We don't want a package to be distributed that causes a segmentation fault when run, across the entire p2p network, that would cause chaos. If a package compile but segfault when launched, then it would cause chaos anyway, as it should do the same on every computer that uses the same configuration/cpu. It would be a fault of the ebuild, so there would be no change at all from what could happend right now. From a security point of view this is a VERY bad idea. A md5 will only tell you if what is sent is the same as what is received. A md5 cannot tell if the executable has been altered or has been trojaned. Any p2p distrubution system must have a centrally generated md5 that guarentees thet the peer downloaded package matches the package on the mirrors. It is simply not feasable to do this for user compiled binary packages because there are too many possible combinations of use flags, CPUs and compiler options. Under no circumstances should a system like this ever be implemented, its just too dangerous. I am not a fan of a generalized p2p package sharing system for portage. Supporting distfiles and GRP is a possibility, but I will not support general community servers like this. I am disappointed that the portage developers don't think p2p is a good idea. The people at Zynot, http://zynot.org/, think otherwise though. I like the idea of p2p ebuilds and packages. ...and when I start getting super annoyed that Gentoo doesn't offer such a feature, then I will probably start writing it myself! Basically, it is possible to establish trust and eliminate bad content in p2p networks -- but perhaps it is not trivial to do this. Here are some of the problems to worry about: * Establishing trust * Establishing quality * Keeping track of many, many versions of the "same" packages and ebuilds (many people may have written their personal version of an ebuild for some program, say spread at http://spread.org/) * Tracking bugs Here are just a few ideas: * Establish authorities to sign off on ebuilds and packages. Basically, if you trust the authority that did the signing, then you can trust the package that was signed. You could even have a package be signed by many authorities to indicate stability, security, compatibility, etc.. * Usage voting -- anytime someone emerges a particular ebuild/package, then it gets a vote (to give an idea of how many people use certain packages, and perhaps to locate popular versions of a package) Why would you want to consider p2p? Well, try these reasons: * Portage is incomplete (ie. missing lots of ebuilds for useful programs)! I have to write my own ebuilds or install stuff in /usr/local all the time. Wouldn't it be great if I could easily share my ebuilds so that other people didn't have to repeat my hard efforts? * In-house-software: perhaps some people have some software that they write in house and the rest of the world doesn't care about. Why should these have to become part of the portage tree? Of course you could use portage overlay, but if portage had some p2p functionality, it would be nice if it could handle this scenario. * University, corporate, or cluster installations could benefit from precompiled package p2p, or they could benefit from ebuilds that are custom tweaked to support special requirements of the university/corporation |