Gentoo Archives: gentoo-dev

From: Yannick Koehler <yannick.koehler@××××××××.com>
To: Nils Decker <nils@×××××××.de>, gentoo-dev@g.o
Subject: Re: [gentoo-dev] Peer-to-Peer?
Date: Fri, 19 Jul 2002 08:04:43
Message-Id: 200207190904.41900.yannick.koehler@colubris.com
In Reply to: Re: [gentoo-dev] Peer-to-Peer? by Nils Decker
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 On July 19, 2002 05:20 am, Nils Decker wrote:
5 > > > propose or take it from the distribution system. Basically the
6 > > > same as ccache ;-)
7 > >
8 > > I like the idea. I was thinking of something similar.
9 > > I think it's possible to hash the use flags used to build
10 > > the package and compare it to the package to be downloaded.
11 >
12 > I see another problem with this. There is no way to make the packages
13 > trusted. In the portage tree, every downloaded file is checked against a
14 > MD5 hash. This means, I have to trust the person who build the port. This
15 > is not a big problem to me, because those people are "near" to the gentoo
16 > core, and everybody can check the MD5s against the official downloads of
17 > the packet.
18 >
19 > I can't do this sort of check agains precompiled binaries, because every
20 > binary would have a different MD5. The only way to check would to compile
21 > the package myself with the same flags, thus defeating the purpose.
22 > Using those binary packages means to trust every user of gentoo, that he
23 > doesn't put trojans or whatever on my system.
24
25 The MD5 hash verification is only providing proof that the file you've
26 transferred between the distribution server and your PC was the same intended
27 by the server on which you did your rsync of the digest files.
28
29 You actually implicitely trust that whoever put the digest files inside the
30 rsync server used "correct" sources tarballs, you could verify that but the
31 process is kind of lenghty as it would be for a binary check too.
32
33 And now because there may be multiple rsync server, that trust is getting less
34 and less meaningful.
35
36 To fix that, one would have to actually use the same PGP signature of the
37 package as the one provided on the original distribution site from the
38 original author.
39
40 - --
41
42 Yannick Koehler
43
44 -----BEGIN PGP SIGNATURE-----
45 Version: GnuPG v1.0.6 (GNU/Linux)
46 Comment: For info see http://www.gnupg.org
47
48 iD8DBQE9OA5ofuKOJNEyL1URAgjIAJ9uevL5x70xa9gpTZsckyivZzAcRQCdEVry
49 YpQYX7E3DVoJtRlhTXQyqpg=
50 =djr/
51 -----END PGP SIGNATURE-----