1 |
Would getting hashes to agree be a hard thing to accomplish? If you use the |
2 |
binary build feature in portage you could save the build in a compressed |
3 |
format. Then have a hash generate set up where it would take the name, |
4 |
version, and use flags, cflags and hash just that information. Have a |
5 |
program that would run as a deamond on compter it could update themselves to |
6 |
something like a torrent tracker. The torrent name could the the hashed |
7 |
values. Then we could have the data that would need to be installed passed |
8 |
via torrent to all other users. It would be an interesting implementation. |
9 |
Also you could use a DC++ idea and have a hub set up where you could only |
10 |
share compiled programs? |
11 |
|
12 |
This would make the idea distributed so it would not have to have ~10451G of |
13 |
space used on any single server. People would host 'packages' as they |
14 |
compiled them. The more comon the program was, the faster the downloads |
15 |
would be. |
16 |
|
17 |
Another use would be releasing common programs/sets as packages? Example, |
18 |
Xorg. There are tons of programs that go along with it. If you host |
19 |
commonly used programs on a service then people could download the program |
20 |
and use it while they compiled it with their own use flags. We could offer |
21 |
programs with all flags enabled, the package manager would go get the |
22 |
prebuild program, keep track of all the files and then start the custom |
23 |
build according to the users own settings. After the build is done, before |
24 |
it is moved from its sandbox, purdge the old files from the downloaded, |
25 |
pre-compiled code, and then move the files from the sand box. |
26 |
|
27 |
On Tue, Mar 24, 2009 at 2:22 AM, <mmacleod@××××××××××.za> wrote: |
28 |
|
29 |
> On Tuesday 24 March 2009 06:41:14 Alec Warner wrote: |
30 |
> > On Mon, Mar 23, 2009 at 4:24 PM, Philipp Riegger <lists@××××××××××××.de> |
31 |
> wrote: |
32 |
> > > On Mon, 23 Mar 2009 08:52:38 +0200 |
33 |
> > > |
34 |
> > > mmacleod@××××××××××.za wrote: |
35 |
> > >><snip> |
36 |
> > > I'm not sure, if this is the right way to go. I'd prefer some kind of |
37 |
> > > build server with better configuration and management than exists at |
38 |
> > > the moment. |
39 |
> At a very rough calculation for just one build server to hold all packages |
40 |
> for |
41 |
> one architecture with only one use flag combination you are looking at |
42 |
> ~0451 |
43 |
> gigabytes of space. This can be reduced somewhat with difference patches |
44 |
> but |
45 |
> then you are stuck spending vast amount of compute times on the differences |
46 |
> and still need a fairly vast amount of hard drive space. |
47 |
> I don't even know how to venture a guess at the compile time for this at |
48 |
> the |
49 |
> moment but I am fairly certain it is completely impractical for now. |
50 |
> The best that could be achieved with a nice build server would be binaries |
51 |
> for |
52 |
> a small subset of what is in portage. This assumes a good dedicated build |
53 |
> server is available for such a thing. |
54 |
> |
55 |
> My idea can function with no build server, and then incorporate build |
56 |
> servers |
57 |
> as they come along so it can take advantage of both. |
58 |
> |
59 |
> In an ideal world Gentoo will have enough build servers to generate them |
60 |
> all |
61 |
> internally and maybe we will get there one day, this idea is scalable so it |
62 |
> could continue to function with just build servers eventually, however I |
63 |
> suspect that we are a long way away from having build server capable of |
64 |
> this. |
65 |
> Feel free to correct me if I am wrong on this though. |
66 |
> > > I'm not sure, if the p2p network is trustworthy enough, |
67 |
> > > even with your hash stuff. What if a user creates a package with some |
68 |
> > > backdoor in it? How would you notice that? |
69 |
> This is just a simple example for now, actual security levels could be more |
70 |
> complex to be even more effective. |
71 |
> Imagine however the following three security levels. |
72 |
> 1) Hash contributed by 100 users |
73 |
> 2) Hash contributed by 1000 users |
74 |
> 3) Hash verified by build server(build server verifies packages from level |
75 |
> 2 |
76 |
> based on popularity and/or a list of "important" packages to prefer) |
77 |
> |
78 |
> Now if a user creates a package with a back door he will have to trick or |
79 |
> collaborate with 100 other users in order to get the people on level 1 |
80 |
> security setting to download his modified sources and compile them all |
81 |
> without |
82 |
> 1 other legit user having a clashing hash, the instant there is a clash his |
83 |
> package will be flagged and action taken. |
84 |
> This is still possible I admit but highly unlikely, especially if users |
85 |
> acting |
86 |
> as "compile hosts" are randomly selected to verify such packages. |
87 |
> |
88 |
> At level 2 security the same thing except now 1000 users all have to agree |
89 |
> on |
90 |
> the package hash. |
91 |
> Even more unlikely. |
92 |
> |
93 |
> At level 3 the package has been compiled by build server itself so the only |
94 |
> way the package can contain a back door is if the server has been |
95 |
> compromised |
96 |
> or the original sources have been compromised. In this case it is no less |
97 |
> secure then our current set up where everyone compiles as it would be |
98 |
> equally |
99 |
> hard to compromise the build server as to get a tainted tarball into the |
100 |
> official portage tree. |
101 |
> |
102 |
> The levels above are just examples, the proper scheme would likely contain |
103 |
> a |
104 |
> few more levels as well as a bit more complexity, however it needs more |
105 |
> thought first and I don't want to get too complex yet, just trying to show |
106 |
> the |
107 |
> basic idea. |
108 |
> |
109 |
> I am sure many users would be happy enough with even level 1 security |
110 |
> packages, I would probably not hesitate to have such packages on my |
111 |
> machine. |
112 |
> For the more paranoid they can wait a bit longer for packages to reach a |
113 |
> higher level or compile it themselves in the meantime. |
114 |
> > >> <snip> |
115 |
> > > |
116 |
> > > Not sure, if this was already discussed: Usually, software has |
117 |
> > > versions. Gentoo adds revisions (these -rX endings) to have different |
118 |
> > > ebuild versions for the same software version. Now, for binary packages |
119 |
> > > we would need another revision-like addition (because there can be |
120 |
> > > pkg-foo-1.2.3 linked against lib-bar:1 and linked against lib-bar:2). |
121 |
> The "Improved binary package support" idea on the wiki as well as the |
122 |
> related |
123 |
> bugzilla thread already cover this as well as possible ways to deal with |
124 |
> it. |
125 |
> > > If I were the buildserver, I would build the new libbar once it is in |
126 |
> > > the tree and then use revdep-rebuild and emerge @preserved-rebuild to |
127 |
> > > figure out, what needs to be rebuilt. Then I would rebuild those |
128 |
> > > packages and increase the, let's call it binary-revision. I'd repeat |
129 |
> > > that until all was fine (which should be the case after 1 iteration, |
130 |
> > > most of the time). |
131 |
> |
132 |
> > > Another thing: Smaller installations. Maybe you could work on moving |
133 |
> > > more software out of @system, that for example gcc does not need to be |
134 |
> > > installed on binary-only hosts. Maybe you could create some |
135 |
> > > INSTALL_MASK files that would make the system smaller leaving out |
136 |
> > > headers, maybe static libraries and stuff like that. What would you |
137 |
> > > think about that one? |
138 |
> > I think "binary only profile" ? |
139 |
> A binary profile would definitely be nice, I don't think it is worth |
140 |
> considering until binaries for most things are largely available first |
141 |
> though. |
142 |
> |
143 |
> |
144 |
> Another nice spin off of having these binaries would be improved multilib |
145 |
> support, portage would need some improvement to handle this, but a 64 bit |
146 |
> user(for example) could have portage get a 32 bit binary for any package |
147 |
> and |
148 |
> run it instead of needing to rely on the "*-bin" packages and/or chroot |
149 |
> when |
150 |
> no -bin is available. |
151 |
> |
152 |
> |
153 |
|
154 |
|
155 |
-- |
156 |
Ethan Hall |
157 |
ekhall@××××××.edu |
158 |
ethankhall@×××××.com |