1 |
> > > Here you have a central server and stuff. Before somebody told me he |
2 |
> > > wants to create the following: A p2p network where all the data is |
3 |
> > > stored in the network (on different peers) and not on a central |
4 |
> > > server. There you get a really distributed system with lots and |
5 |
> > > lots of things to think about and lots and lots of problems to |
6 |
> > > address. |
7 |
> > |
8 |
> > You are completely misunderstanding and incorrectly stating what I |
9 |
> > said by the way. |
10 |
> > I clearly stated in my thread that there would be a central server |
11 |
> > controlling the network, this server would obviously be used for |
12 |
> > things like hashes as well. |
13 |
> > To have the entire thing completely distributed with no central |
14 |
> > control would be absolutely stupid. |
15 |
> > |
16 |
> > If you want people to look at what "somebody" told you please point |
17 |
> > them to the original thread on the mailing list to interpret it for |
18 |
> > themselves instead of telling them stuff which is not true, thanks. |
19 |
> |
20 |
> Sorry, I meant to sum the differences up and had forgotten that fact. |
21 |
> You said "There obviously might be security concerns for users of such |
22 |
> a system, this can be mitigated by using a central controlling server |
23 |
> and by taking Hash signatures of compiled packages from users other |
24 |
> then the original contributer." which mentions a central server. |
25 |
> |
26 |
> But what exactly would it do? Store hashes? Calculate hashes? Store |
27 |
> metadata? Where does it get that from? |
28 |
The central server would store various information on packages residing in the |
29 |
system as well as authentication details for users. |
30 |
For packages it would store: |
31 |
* A trust level for the package.[1] |
32 |
* A hash of the package tarball to be used after a download to ensure the file |
33 |
has been downloaded correctly - used by all downloaders. |
34 |
* A hash of the internals of the package tarball to be used when verifying |
35 |
that somebodies provided package is not a tampered with one that has a rootkit |
36 |
in for example. - provided by anyone who generates a package. |
37 |
* Records of who provided the package and who has verified its integrity with |
38 |
the above hash. |
39 |
* A torrent file for the package.(Not necessarily torrents just an example, |
40 |
the server would act as the tracker for all torrents as well or potentially a |
41 |
seperate server) |
42 |
* Other inconsequential but useful stuff like number of download requests per |
43 |
package etc.. |
44 |
|
45 |
[1] The trust level could be as fine grained as one liked, it could start out |
46 |
with just a few different levels and as the system grows be made more fine |
47 |
grained if necessary. |
48 |
An example of how the levels might look(in decreasing order of trust) but this |
49 |
is by no means concrete yet: |
50 |
1/ Package compiled by central Gentoo build server. |
51 |
2/ Package compiled by more then one trusted user.(Gentoo developer) |
52 |
3/ Package compiled by trusted user. |
53 |
4/ Package compiled by X quantity of semi-trusted users.(Contributers who have |
54 |
been deemed trustworthy enough to be marked as such) |
55 |
5/ Package compiled by semi-trusted user. |
56 |
6/ Package compiled by X quantity of untrusted users. |
57 |
|
58 |
The system would always seek to upgrade the trust of a package where possible |
59 |
so if a package is currently on level 4 trust and then a Gentoo developer |
60 |
compiles it the trust for that package would then rise to level 2. Unless of |
61 |
course the internal hash did not match in which case other action would then |
62 |
be taken... |
63 |
The compile server(s) would work tirelessly attempting to upgrade as many |
64 |
packages as possible to level 1 trust, starting with the more popular ones |
65 |
first. In doing so they would also be keeping a check up on the users who |
66 |
compiled it before them as it can compare internal hashes and take action when |
67 |
clashes are found. |
68 |
|
69 |
The central server would also be in charge of various other things like |
70 |
choosing users to host copies of packages when new packages become available. |
71 |
|
72 |
When a user wants to emerge something, emerge would query the package server |
73 |
and ask if a package to suit its needs(including security level) is available, |
74 |
if one is then the server would reply with a .torrent file to download. The |
75 |
client would then download the package over the torrent and then emerge would |
76 |
emerge it as a package. |
77 |
If no suitable package is available emerge will instead just act as normal and |
78 |
compile the package itself, and then potentially make the result available to |
79 |
the server so that others can benefit from it. |
80 |
|
81 |
The acceptable trust level is something the user would decide on, so people |
82 |
who are extremely paranoid(whether it be with a good reason or not) and don't |
83 |
trust even the Gentoo devs can accept only level 1 packages, while others can |
84 |
accept level 5/6 packages if they want. |
85 |
> So if I understand it right, for building packages you use some |
86 |
> client-server system and for distributing them you have a central |
87 |
> server to get information from and download packages using the p2p |
88 |
> network? |
89 |
That sounds about right yes. |