On Mon, 27 Nov 2006 13:02:17 +0000
"Stuart Herbert" <[EMAIL PROTECTED]> wrote:

> On 11/27/06, paul <[EMAIL PROTECTED]> wrote:
> > You can't take workload out of the picture since it's the main issue
> > here. Stable tree means backport fixes and I don't see this
> > happening as it can't be automated:
> 
> "Stable tree means backport fixes" is an assumption, not a
> requirement.
> 
> It's one reason why the word "stable" is a poor choice for any such
> tree, just as it is a poor choice for the current Portage tree.
> 
> I think the original poster hit the nail on the head.  The real
> barrier preventing a slower-moving tree is cultural.

One method could be to snapshot all package versions at the time that
Release Engineering make a release, building a package.mask file out of
it masking out all packages of higher revisions (i.e. having '>CPVR'
entry for every package in the tree in stable, and 'CPVR' if no
versions are stable).

Then, rather than back-port security fixes, this list would be updated
with security-fixed version numbers, along with minimum required updates
to dependent packages. The lists could be stored in the tree; for
example as profiles/default-linux/x86/stable.mask.

Obviously maintaining that list is some work; predominantly watching
the announcements from the security team and fixing up dependencies,
and masking out new packages (for what that's worth).  It could be
regenerated on some or all releases, or perhaps on a yearly basis.  It
would also mean that versions listed there cannot be removed from the
tree (until they're bumped in the list).

Some of that maintenance could be tool-assisted; in particular masking
new packages and finding the minimum required bumps to support a
package that was bumped for a security fix.

People who want to use it could then just soft-link
from /etc/portage/package.mask to that list.

It's just a suggestion - I'm not prepared to do the work ;)  However it
might be a simple but effective method to help people maintain secure
but relatively stable systems, without having to upgrade umpteen
packages a week.

-- 
Kevin F. Quinn

Attachment: signature.asc
Description: PGP signature

Reply via email to