Would getting hashes to agree be a hard thing to accomplish? If you use the binary build feature in portage you could save the build in a compressed format. Then have a hash generate set up where it would take the name, version, and use flags, cflags and hash just that information. Have a program that would run as a deamond on compter it could update themselves to something like a torrent tracker. The torrent name could the the hashed values. Then we could have the data that would need to be installed passed via torrent to all other users. It would be an interesting implementation. Also you could use a DC++ idea and have a hub set up where you could only share compiled programs?<br>
<br>This would make the idea distributed so it would not have to have ~10451G of space used on any single server. People would host 'packages' as they compiled them. The more comon the program was, the faster the downloads would be.<br>
<br>Another use would be releasing common programs/sets as packages? Example, Xorg. There are tons of programs that go along with it. If you host commonly used programs on a service then people could download the program and use it while they compiled it with their own use flags. We could offer programs with all flags enabled, the package manager would go get the prebuild program, keep track of all the files and then start the custom build according to the users own settings. After the build is done, before it is moved from its sandbox, purdge the old files from the downloaded, pre-compiled code, and then move the files from the sand box.<br>
<br><div class="gmail_quote">On Tue, Mar 24, 2009 at 2:22 AM, <span dir="ltr"><<a href="mailto:mmacleod@...">mmacleod@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tuesday 24 March 2009 06:41:14 Alec Warner wrote:<br>
> On Mon, Mar 23, 2009 at 4:24 PM, Philipp Riegger <<a href="mailto:lists@...">lists@...</a>><br>
wrote:<br>
> > On Mon, 23 Mar 2009 08:52:38 +0200<br>
> ><br>
> > <a href="mailto:mmacleod@...">mmacleod@...</a> wrote:<br>
</div>> >><snip><br>
<div class="im">> > I'm not sure, if this is the right way to go. I'd prefer some kind of<br>
> > build server with better configuration and management than exists at<br>
> > the moment.<br>
</div>At a very rough calculation for just one build server to hold all packages for<br>
one architecture with only one use flag combination you are looking at ~0451<br>
gigabytes of space. This can be reduced somewhat with difference patches but<br>
then you are stuck spending vast amount of compute times on the differences<br>
and still need a fairly vast amount of hard drive space.<br>
I don't even know how to venture a guess at the compile time for this at the<br>
moment but I am fairly certain it is completely impractical for now.<br>
The best that could be achieved with a nice build server would be binaries for<br>
a small subset of what is in portage. This assumes a good dedicated build<br>
server is available for such a thing.<br>
<br>
My idea can function with no build server, and then incorporate build servers<br>
as they come along so it can take advantage of both.<br>
<br>
In an ideal world Gentoo will have enough build servers to generate them all<br>
internally and maybe we will get there one day, this idea is scalable so it<br>
could continue to function with just build servers eventually, however I<br>
suspect that we are a long way away from having build server capable of this.<br>
Feel free to correct me if I am wrong on this though.<br>
<div class="im">> > I'm not sure, if the p2p network is trustworthy enough,<br>
> > even with your hash stuff. What if a user creates a package with some<br>
> > backdoor in it? How would you notice that?<br>
</div>This is just a simple example for now, actual security levels could be more<br>
complex to be even more effective.<br>
Imagine however the following three security levels.<br>
1) Hash contributed by 100 users<br>
2) Hash contributed by 1000 users<br>
3) Hash verified by build server(build server verifies packages from level 2<br>
based on popularity and/or a list of "important" packages to prefer)<br>
<br>
Now if a user creates a package with a back door he will have to trick or<br>
collaborate with 100 other users in order to get the people on level 1<br>
security setting to download his modified sources and compile them all without<br>
1 other legit user having a clashing hash, the instant there is a clash his<br>
package will be flagged and action taken.<br>
This is still possible I admit but highly unlikely, especially if users acting<br>
as "compile hosts" are randomly selected to verify such packages.<br>
<br>
At level 2 security the same thing except now 1000 users all have to agree on<br>
the package hash.<br>
Even more unlikely.<br>
<br>
At level 3 the package has been compiled by build server itself so the only<br>
way the package can contain a back door is if the server has been compromised<br>
or the original sources have been compromised. In this case it is no less<br>
secure then our current set up where everyone compiles as it would be equally<br>
hard to compromise the build server as to get a tainted tarball into the<br>
official portage tree.<br>
<br>
The levels above are just examples, the proper scheme would likely contain a<br>
few more levels as well as a bit more complexity, however it needs more<br>
thought first and I don't want to get too complex yet, just trying to show the<br>
basic idea.<br>
<br>
I am sure many users would be happy enough with even level 1 security<br>
packages, I would probably not hesitate to have such packages on my machine.<br>
For the more paranoid they can wait a bit longer for packages to reach a<br>
higher level or compile it themselves in the meantime.<br>
> >> <snip><br>
<div class="im">> ><br>
> > Not sure, if this was already discussed: Usually, software has<br>
> > versions. Gentoo adds revisions (these -rX endings) to have different<br>
> > ebuild versions for the same software version. Now, for binary packages<br>
> > we would need another revision-like addition (because there can be<br>
> > pkg-foo-1.2.3 linked against lib-bar:1 and linked against lib-bar:2).<br>
</div>The "Improved binary package support" idea on the wiki as well as the related<br>
bugzilla thread already cover this as well as possible ways to deal with it.<br>
<div class="im">> > If I were the buildserver, I would build the new libbar once it is in<br>
> > the tree and then use revdep-rebuild and emerge @preserved-rebuild to<br>
> > figure out, what needs to be rebuilt. Then I would rebuild those<br>
> > packages and increase the, let's call it binary-revision. I'd repeat<br>
> > that until all was fine (which should be the case after 1 iteration,<br>
> > most of the time).<br>
<br>
</div><div class="im">> > Another thing: Smaller installations. Maybe you could work on moving<br>
> > more software out of @system, that for example gcc does not need to be<br>
> > installed on binary-only hosts. Maybe you could create some<br>
> > INSTALL_MASK files that would make the system smaller leaving out<br>
> > headers, maybe static libraries and stuff like that. What would you<br>
> > think about that one?<br>
> I think "binary only profile" ?<br>
</div>A binary profile would definitely be nice, I don't think it is worth<br>
considering until binaries for most things are largely available first though.<br>
<br>
<br>
Another nice spin off of having these binaries would be improved multilib<br>
support, portage would need some improvement to handle this, but a 64 bit<br>
user(for example) could have portage get a 32 bit binary for any package and<br>
run it instead of needing to rely on the "*-bin" packages and/or chroot when<br>
no -bin is available.<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Ethan Hall<br><a href="mailto:ekhall@...">ekhall@...</a><br><a href="mailto:ethankhall@...">ethankhall@...</a><br>
|
