Re: [gentoo-security] courier-imap

[Matt Hallmark]

As someone interested in these happenings, I might point you at the most 
recent Gentoo Weekly Newsletter.

http://www.gentoo.org/news/en/gwn/20040322-newsletter.xml

In it glsa-check is mentioned as a new means to identify security issues 
in gentoo.  It'll eventually me merged into emerge (heh) in the future.

This doesn't do us much good if the issue is never declared as a GLSA 
though, which seems to be Ben's main problem here.

Matt Hallmark

Ben Cressey wrote:

> 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
>

--
gentoo-security@g.o mailing list