1 |
On Sun, Nov 07, 2004 at 11:26:55PM +0000, Kurt Lieber wrote: |
2 |
> If you believe this happens for even 20% of the packages in our tree, |
3 |
> you're mistaken. Most devs look at changelogs. Few devs look at code |
4 |
> diffs. Note I did not say "Gentoo devs". |
5 |
|
6 |
I hope they at least check the signatures of the packages that have them |
7 |
available. |
8 |
|
9 |
This would be an interesting poll question, if we could get a number |
10 |
of devs to participate (and not just Gentoo devs). :-) |
11 |
|
12 |
I know I look at code diffs for packages that matter to me, and have done |
13 |
code audits of certain software I rely on for security. I do realize that |
14 |
there is the ever-present time constraints, but part of the advantage |
15 |
of having multiple maintainers for a distro is that this kind of work |
16 |
can be spread around. |
17 |
|
18 |
> Signed ebuilds in portage is something that is already implemented |
19 |
> and supported as an experimental feature as of 2.0.51: |
20 |
> |
21 |
> http://www.gentoo.org/news/20041021-portage51.xml |
22 |
|
23 |
Given this release is only 2.5 weeks old, I hope you'll pardon my not |
24 |
knowing this. :-) I'm quite pleased to see that this has reached the |
25 |
experimental stage. |
26 |
|
27 |
I just downloaded a fresh portage tree to take a look, and I notice |
28 |
that signatures are making their way into the Manifest files. Is this |
29 |
an automated process? If so, can we expect all the Manifest files to |
30 |
soon be signed? |
31 |
|
32 |
> The original poster was talking about the inability to verify *eclasses*, |
33 |
> not ebuilds. eclasses are an important part of portage from a features and |
34 |
> functionality perspective, but they make up a small fraction of the overall |
35 |
> tree in terms of sheer number of files. My point was and still is that |
36 |
> investing the time and effort to also sign these files isn't worth it given |
37 |
> the myriad of other larger holes that already exist further upstream. |
38 |
|
39 |
Wouldn't it be sufficient to put a Manifest file in the eclass/ directory |
40 |
and sign it as well? |
41 |
|
42 |
> Or, to leverage one of the primary tenets of FOSS -- if there are folks on |
43 |
> the list who truly believe this is a hole that should be fixed, provide |
44 |
> patches to portage to add this functionality. It already supports signing |
45 |
> to some degree -- one could reasonably assume that adding support for |
46 |
> signing of eclasses is relatively easy for a competent python programmer. |
47 |
|
48 |
I note you mention this often, and I do appreciate the need for people |
49 |
to join in and help out. The main roadblock to implementing new signing |
50 |
procedures, for the outsider, is that it requires access to the server |
51 |
to implement the signing, or it requires participation from all devs, |
52 |
depending on the method chosen. |
53 |
|
54 |
Given this roadblock, I don't think it is completely fair to lay this job |
55 |
at users' feet. |
56 |
|
57 |
What I'm trying to say is that signing doesn't have to be implemented for |
58 |
the end user in portage before it is implemented on the server. Once the |
59 |
signatures are available on the server, all this talk would go away, and |
60 |
those that are concerned would do the checks, and those that aren't |
61 |
wouldn't. The concerned would likely share their checking scripts as well. |
62 |
|
63 |
So, I'm quite happy that there are experimental features in portage that |
64 |
deal with this, but I'd be even happier if every Manifest file in the |
65 |
portage tree was signed, even if portage code didn't do the checks yet. |
66 |
|
67 |
- Chris |
68 |
|
69 |
|
70 |
-- |
71 |
gentoo-security@g.o mailing list |