1 |
Kurt Lieber wrote: |
2 |
> This would only be done in the most extreme cases, of which this is not |
3 |
> one. |
4 |
|
5 |
That policy makes sense, I admit. I'm not trying to blow this out of |
6 |
proportion (and I notice that the new courier-imap ebuild is available in |
7 |
stable at the moment), just trying to realign my assumptions about gentoo |
8 |
and security with the reality of the process. |
9 |
|
10 |
I've been giving it some thought this morning, and I have a question. Would |
11 |
it be feasible to add architecture-specific "security" keywords, such as |
12 |
+x86 alongside ~x86 and x86? +x86 would have the following differences over |
13 |
mainline x86: |
14 |
|
15 |
1) Any ebuild with a known security flaw would be removed immediately. |
16 |
2) Old ebuilds would never "age out" of this keyword. |
17 |
|
18 |
Users could then set this keyword instead of the default x86, and could run |
19 |
emerge with a "--securityupdate" option that would only suggest upgrading |
20 |
packages that were installed and no longer part of +x86. |
21 |
|
22 |
Point #2 seems to be the most problematic, simply because older ebuilds are |
23 |
routinely deleted as the portage tree is updated and new versions become |
24 |
available. Two solutions come to mind for this difficulty: |
25 |
|
26 |
1) A "stub" of the old ebuild could be left in portage; this ebuild would |
27 |
not be enough to install the package, but would have the minimum set of |
28 |
information required to act as a valid ebuild for that version, for the |
29 |
purposes of the emerge --securityupdate check. |
30 |
|
31 |
2) Alternatively, users with the +x86 keyword set would not have old ebuilds |
32 |
deleted from their portage tree during the rsync process. |
33 |
|
34 |
The difficulty with point #2 would be that package maintainers would have no |
35 |
way to go back and remove the +x86 keyword from an old version of the ebuild |
36 |
if that ebuild was no longer in portage. The problem with #1 seems to be |
37 |
that the number of ebuilds in the portage tree would continue to grow over |
38 |
time, and if a vulnerability was found, maintainers would potentially have |
39 |
dozens of old ebuilds to remove from +x86. #2 is probably the best |
40 |
approach, if the difficulty can be overcome. |
41 |
|
42 |
Perhaps a "security.mask" could be added alongside package.mask, and older, |
43 |
out of tree versions of ebuilds affected by a security vulnerability could |
44 |
be masked from +x86 that way. |
45 |
|
46 |
Ben |
47 |
|
48 |
|
49 |
-- |
50 |
gentoo-security@g.o mailing list |