Gentoo Archives: gentoo-hardened

From: Joshua Brindle <method@g.o>
To: jeremy@××××××××××.com
Cc: gentoo-core@g.o, gentoo-hardened@g.o, gentoo-security@g.o
Subject: Re: [gentoo-hardened] The state of ebuild signing in portage
Date: Sat, 19 Apr 2003 16:43:15
Message-Id: 20030419T114258Z_B95E00150000@gentoo.org
1 >It sounds like a lot of work has been done on this.
2
3 indeed.
4
5 >My biggest concern is that this seems to be ignoring the projects that
6 >are already signing their packages. I know that many projects already
7 >sign their packages (check out Apache, MySQL, etc) and I believe that
8 >your proposed implementation is disregarding these signatures and the
9 >existing web of trust that they represent.
10
11 Well, IMO it isn't portages responsibility to check this sort of thing, it's
12 the responsibility of the developer handling those particular ebuilds.
13
14 the major purpose of what we are doing is to ensure that nothing in the
15 portage tree has been compromised. Far too few projects do signing
16 upstream, and their is no standard way of handling it, so it would be
17 far to difficult to incorporate this into portage itself.
18
19 >With your way of doing it, if I'm understanding correctly, you're
20 >ensuring that the ebuild we download is as the ebuild author intended
21 >it. But, are we sure that the tarball that is downloaded by the ebuild
22 >is as the package creator intended it? Are we checking that Apache
23 >signed the package that is being downloaded? I know an MD5 sum is
24 >checked, but where does that come from? Does the ebuild maintainer
25 >get that from the same site that the tarball comes from? What if the
26 >tarball is trojaned and then the md5 sum is replaced?
27
28 Again, the devs responsible should ensure that the source they have and
29 commit are authentic.
30
31 >Is there a way to incorporate this existing method instead of
32 >replacing it or ignoring it? The reason it's called a Web Of Trust
33 >is that existing keys can be used to verify new,unknonw, keys. By
34 >disregarding the existing practice of signing distributed packages,
35 >I'm not sure that this implementation is truly using that existing
36 >practice that works when utilized properly.
37
38 same ^^
39
40 >Otherwise, great work! I'm looking forward to using this on a daily
41 >basis.
42
43 Thanks :)
44
45
46 --
47 gentoo-hardened@g.o mailing list