Re: [gentoo-security] courier-imap

[William Kenworthy]

appears its got a way to go yet: it warms on xfree and a number of other
packages that have been updated to the secure versions, so dont rely on
it yet!  I worry that if its reporting packages that have been fixed,
what is it missing?  However, its early days yet and maybe the next
version will improve.

BillK

On Fri, 2004-03-26 at 23:09, Matt Hallmark wrote:
> 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