Kurt Lieber wrote:
> This would only be done in the most extreme cases, of which this is not
> one.

That policy makes sense, I admit.  I'm not trying to blow this out of
proportion (and I notice that the new courier-imap ebuild is available in
stable at the moment), just trying to realign my assumptions about gentoo
and security with the reality of the process.

I've been giving it some thought this morning, and I have a question. Would
it be feasible to add architecture-specific "security" keywords, such as
+x86 alongside ~x86 and x86?  +x86 would have the following differences over
mainline x86:

1) Any ebuild with a known security flaw would be removed immediately.
2) Old ebuilds would never "age out" of this keyword.

Users could then set this keyword instead of the default x86, and could run
emerge with a "--securityupdate" option that would only suggest upgrading
packages that were installed and no longer part of +x86.

Point #2 seems to be the most problematic, simply because older ebuilds are
routinely deleted as the portage tree is updated and new versions become
available.  Two solutions come to mind for this difficulty:

1) A "stub" of the old ebuild could be left in portage; this ebuild would
not be enough to install the package, but would have the minimum set of
information required to act as a valid ebuild for that version, for the
purposes of the emerge --securityupdate check.

2) Alternatively, users with the +x86 keyword set would not have old ebuilds
deleted from their portage tree during the rsync process.

The difficulty with point #2 would be that package maintainers would have no
way to go back and remove the +x86 keyword from an old version of the ebuild
if that ebuild was no longer in portage.  The problem with #1 seems to be
that the number of ebuilds in the portage tree would continue to grow over
time, and if a vulnerability was found, maintainers would potentially have
dozens of old ebuilds to remove from +x86.  #2 is probably the best
approach, if the difficulty can be overcome.

Perhaps a "security.mask" could be added alongside package.mask, and older,
out of tree versions of ebuilds affected by a security vulnerability could
be masked from +x86 that way.

Ben


--
gentoo-security@g.o mailing list