Re: [gentoo-security] courier-imap

[Ben Cressey]

Interesting read, thanks for the link.

Ben

----- Original Message ----- 
From: "Matt Hallmark" <matt@×××××××××××××.com>
To: <gentoo-security@l.g.o>
Sent: Friday, March 26, 2004 10:09 AM
Subject: Re: [gentoo-security] courier-imap


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


--
gentoo-security@g.o mailing list