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 |