Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Oct 2000 18:03:37 -0700
From:      Michael Bryan <fbsd-security@ursine.com>
To:        freebsd-security@FreeBSD.ORG
Cc:        cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: How long for -stable [ Re: cvs commit: src/usr.bin/finger finger.c ]
Message-ID:  <39DA81E9.FD461622@ursine.com>
References:  <paul@originative.co.uk> <84222.970618959@winston.osd.bsdi.com> <20001003173414.A58372@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


Kris Kennaway wrote:
> 
> On Tue, Oct 03, 2000 at 05:22:39PM -0700, Jordan Hubbard wrote:
> 
> > I would therefore like to propose the following: We change the wording
> > of our policy to state that upgrading to something within two releases
> > of the "current -stable" product is the *recommended* action but that
> > we will continue to provide, WHERE POSSIBLE, support for older
> > branches of FreeBSD.  We also stop telling people running 3.x (or

I like this.  A lot.

> I suggest that in practise it will be all but impossible for people to
> get active bugfix support for 3.x, and we'd probably be giving a false
> impression if we say otherwise.
> [...]
> Speaking for myself as part of the security team, I don't want to
> support 3.x for security fixes any more, since it's been just too damn
> hard to do that over the past few months (i.e. in fact we havent been
> providing good security support because developers aren't backporting
> security fixes), and as warner pointed out we've now passed our "3
> releases along a branch" cutoff policy.

Well, it's been said before, but I'll add my two cents to this.  Support
for at least security-related issues really needs to be provided for a
reasonable duration, probably about a year, maybe longer, after a release
comes out.  Some production environments need (or at least strongly desire)
this in order to more cautiously roll out full-on upgrades in a more
planned mode of operation, where planning/testing/rollout can take many
months, up to a significant part of a year.  Shortcuts/quickfixes can be
done in a more timely fashion when an urgent problem can be fixed with
a relatively isolated patch or utility update, but that's frequently much
harder to get approved when you're talking about a full upgrade that touches
a lot more of the system.

Having a cutoff based on number of releases just isn't realistic for the way
a lot of production sites operate, not when the releases come out in relatively
quick succession.  4.0 came out in March, and 4.1 in July.  A lot of sites are
hesitant to upgrade to any x.0 point release (whether or not FreeBSD warrants
that caution is a separate issue, it -is- a real concern a lot of companies
face and have been burned by.)  So it's extremely unrealistic to tell them
"Yes, you rolled out 3.5 in June when it first came out, but now you have to do
a major upgrade to 4.x to get security fix 'foobar', even though your schedule
for rollout says you were going to do it in November/December".  :-/

If FreeBSD does -not- do this, I strongly feel that a lot of potential users
of it will simply say "Sorry, we need at least one year of critical bug/security
fix support on any given release tree, so we'll go with somebody who can give
us that."

I know this has been discussed before, but since Jordon has stepped up to the
plate with what I think is an extremely realistic and workable framework for
release support, I wanted to try to make sure that gets supported, and not
shot down.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39DA81E9.FD461622>