Re: [gentoo-dev] GLEP 14 follow-up / security project

[Matt Thrailkill]

Is the end result supposed to be that someone could have a box get
updates in response to GLSAs withouting doing an emerge rsync and a
world update?

Seems like right now, when a GLSA is issued, they say "update to this
version" to fix yourself.  Which involves an rsync.  So the ebuild to
fix the security hole isn't explicitly for security, its just another
ebuild as far as Portage knows.

And so if the idea is that someone running a server is wanting to
abstain from CONSTANTLY updating everything for nothing, but DOES want
to snag the security updates, this method is a little sloppy, since he'd
have to rsync and eventually if he abstained too long, the new ebuilds
to fix security flaws might not work due to deps on other things.

Debian, for example, backports the security fixes for Woody - your
software doesn't really change after you patch.

Myself, I grabbed the 1.4.1 Portage snapshot and I plan to manually add
the GLSAs to that and have my stable boxes rsync from that.  So really
the only changes they'd get would be GLSAs, sort of like woody.

Maybe for people who don't want to lock themselves to a portage
snapshot, there could be something like --glsa to be used in conjunction
with `emerge rsync` to tell it *just* to pull down the glsa-related
ebuilds.

I guess my wandering point is that emerging rsync and then updating
worlds catches GLSA now, but obviously that involves alot of
time-wasting for a server box.  So a glsa-specific technique would mean
omitting a full rsync and/or world update.  But then you'll have to deal
with the fact that the people just wanting to put glsa updates on
machines will all have machines with wildly varying versions of software
and portage trees.  So how would that be resolved?

--
gentoo-dev@g.o mailing list