Date: Fri, 29 Sep 2000 17:12:15 -0700 From: Michael Bryan <fbsd-security@ursine.com> To: security@FreeBSD.ORG Subject: Re: Status of FreeBSD-SA-00:41.elf? Message-ID: <39D52FDF.2D08F04D@ursine.com> References: <200009280516.e8S5Gi507297@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Brian F. Feldman" wrote: > I should say we would do well to stop "supporting" 3.X anymore and let > people know (a bit louder perhaps?) 3.5 is the end of the line for 3.X and > the proper solution is an upgrade to _4.X_. It's simply not very > interesting or useful to be supporting something that should be phased out > instead of "sorta upgraded" to the latest small increment of a quietly > dying line. I really have to disagree with this. 4.0-RELEASE came out in March of this year, just a little over six months ago, and 4.1-RELEASE came out in July, just over two months ago. Are you really willing to say "sorry, you're not supported" to production environments that brought up FreeBSD 3.x in the first quarter of this year, or especially those that tend to be wary of ".0" releases, and that might have installed a 3.5 base just three months ago? I can understand saying feature additions are only in the new line of development, and have no problem with that. But the reality is that many production environments have a relatively long cycle of testing and approving configurations, especially for significant upgrades. Also, many environments take a cautious approach to version rollouts, and do not want to be in the first wave of people using a new release, especially a ".0" release. (At my current job, I am building up a set of 4.1.1 DNS/Mail/Proxy servers that are going to replace a set of servers that are currently running a combination of 3.4 and 3.5. The current schedule is to go live with them in November as part of other changes going on here, although if major security issues came up, I -might- be able to push that up. But I'd have an easier time justifying a patch on top of 3.5 for all the systems, until the scheduled cutover date.) At the very least, security fixes should be available for version N.x for a year or more after M.x comes out (M=N+1). If possible, even longer. Yes, I know that's a resource commitment, and as code diverges, it gets harder and harder to apply even just the security subset of changes back to older verions. I also know that with "Internet Time", and the frequent releases of FreeBSD, that means an ever increasing number of versions to support for security fixes. But if you cut that support time too short, a lot of commercial interests will be alienated, and will very likely say "Hmmm, they won't provide a security patch for the version we just rolled out five months ago, and instead we have to fully upgrade everybody? Maybe we want to go with some other solution instead." And before you or anybody asks, although I wish I could do the the effort myself to help out the FreeBSD project, including things like security support for older versions, I personally do not have the time to be involved in that level of work. So yeah, that means I'm asking y'all to do things that I cannot directly help you with, other than the usual "buy the CDs" and "promote FreeBSD to others", and I know that means I don't really get -that- much say. :-) I know there is only so much that the FreeBSD team can do, but I do want to push for strong consideration of long-life support of old releases for security-related issues. 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?39D52FDF.2D08F04D>