| 1 |
On Mon, 30 Mar 2009 11:56:27 -0400 |
| 2 |
Caleb Cushing <xenoterracide@×××××.com> wrote: |
| 3 |
|
| 4 |
> On Mon, Mar 30, 2009 at 10:37 AM, Philipp Riegger |
| 5 |
> <lists@××××××××××××.de> wrote: |
| 6 |
> > And how will you find and identify trustworthy people? |
| 7 |
> |
| 8 |
> I'm going to to cover trust just once. |
| 9 |
> |
| 10 |
> people who are already verified as being members of the gentoo |
| 11 |
> organization. e.g. have an @gentoo.org email. |
| 12 |
> |
| 13 |
> the same thing that stops you from doing this as a developer, nothing, |
| 14 |
> how do I know your patches that you've added with epatch or the sed |
| 15 |
> ones don't do this now? this is stupid, you either trust the devs |
| 16 |
> working on stuff or you don't. you can't have an in between, if you |
| 17 |
> have people working for you that you don't trust you have a huge |
| 18 |
> problem. In fact if the toolchain people wanted they could backdoor |
| 19 |
> something that ssh relies on to build, or use and leave ssh |
| 20 |
> vulnerable, so without a full tree audit it's impossible to know. hell |
| 21 |
> if you could patch all editors on the system to not display a line in |
| 22 |
> a certain file... how long would it take you to find that? |
| 23 |
> |
| 24 |
> security is not the issue with binary repositories, please don't |
| 25 |
> discuss security as an issue further, we can implement it well enough. |
| 26 |
> (currently to hack a bunch of gentoo systems all one has to do is take |
| 27 |
> control of a single rsync mirror) |
| 28 |
|
| 29 |
This all is true, but there are steps towards signing ebuilds and that |
| 30 |
stuff. If we now make a totally open system for binary packages, it is |
| 31 |
a step in the other direction. Sure, you can make the gpg and web of |
| 32 |
trust stuff, but what if somebody I don't trust uploads a package? Can |
| 33 |
I reupload it? If a gentoo dev builds it, will the existing one be |
| 34 |
overwritten with his one? This would at least be an interesting |
| 35 |
approach. |
| 36 |
|
| 37 |
What do you think of something like: |
| 38 |
|
| 39 |
3 Groups of people: A) Gentoo devs with commit rights to the tree, B) |
| 40 |
Other Gentoo devs, Arch testers, C) everybody. Packages can be |
| 41 |
uploaded, but A overwrites B and C and B overwrites C. Would something |
| 42 |
like that make sense? Letting people upload a package multiple times |
| 43 |
would waste disk space. |
| 44 |
|
| 45 |
> >> For convenience it would be great, if people could tellportage |
| 46 |
> >> their builder- ID and have portage upload generated packages |
| 47 |
> >> automatically. |
| 48 |
> |
| 49 |
> perhaps it should only be certain packages, you maintain package X |
| 50 |
> it's uploaded when you build, the problem comes to what things have |
| 51 |
> been built against. |
| 52 |
|
| 53 |
Then you get a closed group again. But this is definitively not the p2p |
| 54 |
approach anymore which was described to me before. What we are talking |
| 55 |
about here makes sense, it's something like the same system other |
| 56 |
distributions use. |
| 57 |
|
| 58 |
> what I want to know is how you solve the problem of moving toolchain |
| 59 |
> and deps? what if I upgrade glibc on my system? that could totally |
| 60 |
> break all binary compatibility with any package, how are you going to |
| 61 |
> define what version of what deps a package was built against. |
| 62 |
|
| 63 |
It can definitely be done. Now, it might not be stable yet but there is |
| 64 |
the "preserve libs" feature of portage. If you upgrade a lib the old |
| 65 |
one does not get deleted if binaries still depend on it. This will help |
| 66 |
prevent problems on upgrades. |
| 67 |
|
| 68 |
Problems on installs can be of the nature, that you either have a newer |
| 69 |
or older lib than is needed for the package. If your lib is older, |
| 70 |
simply upgrade the library or don't use the binary package. If your lib |
| 71 |
is newer, build a binary package and upload it. |
| 72 |
|
| 73 |
Now, we get problems here with keywords. Either we only allow binary |
| 74 |
packages for stable systems or only for homogeneous systems, everything |
| 75 |
else will be too complicated and not worth the effort. You should be |
| 76 |
able to override this (mix stable with testing packages), but no |
| 77 |
guarantees there and you should not be allowed to upload the generated |
| 78 |
packages. |
| 79 |
|
| 80 |
As I see it, if portage checks packages before installing them (binary |
| 81 |
ones), not that much can go wrong. I recommend my "binary revision" |
| 82 |
idea here, again, to point out if binary packages have changed without |
| 83 |
the package having been changed. |
| 84 |
|
| 85 |
Another, more drastic idea could be implemented using subversion or |
| 86 |
something like that: For every commit (of a binary package), unpack it, |
| 87 |
check all the included binary files (libs, binaries), if a library is |
| 88 |
included check all the files depending on it (from a database), if |
| 89 |
everything is fine, accept the package and add the created data to the |
| 90 |
database. If there is a problem, make sure the user uploads a |
| 91 |
fixed binary in the same commit. This will be expensive, though, |
| 92 |
because if somebody upgrades a lib lots of packages depend on... |
| 93 |
|
| 94 |
This second idea could be transformed into a third one: Just do the |
| 95 |
"unpack and store infos in a database"-stuff and from there calculate |
| 96 |
which packages are broken because of what lib. Provide that info on a |
| 97 |
web application. |
| 98 |
|
| 99 |
|
| 100 |
If we really want to create a binary distribution, there's no way |
| 101 |
around putting much much more effort into it or building it on one |
| 102 |
server which checks and rechecks everything until all is fine. If we |
| 103 |
see binary packages as another service for our users, we should make |
| 104 |
sure that portage checks for binary dependencies and builds the package |
| 105 |
from source if something goes wrong. |
| 106 |
|
| 107 |
Philipp |
Archives