Date: Tue, 03 Oct 2000 19:07:41 -0700 From: Jordan Hubbard <jkh@winston.osd.bsdi.com> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: Paul Richards <paul@originative.co.uk>, Christopher Masto <chris@netmonger.net>, Warner Losh <imp@village.org>, Joseph Scott <joseph.scott@owp.csus.edu>, Brian Somers <brian@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: How long for -stable [ Re: cvs commit: src/usr.bin/finger finger.c ] Message-ID: <85378.970625261@winston.osd.bsdi.com> In-Reply-To: Message from Kris Kennaway <kris@FreeBSD.ORG> of "Tue, 03 Oct 2000 17:34:14 PDT." <20001003173414.A58372@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Oh, I dunno, I think you may still be operating from the old "economic assumptions" with these concerns. We have a lot more people than we used, after all, to and just the general buy-in to this thread so far would tend to indicate that interest level in legacy support is higher than it has been in recent memory. We just need more volunteers who are committed to r.v-stable (-solid? -stale?) and its upkeep, something which I'd expect to be somewhat easier to recruit part-time help for than -current since the pace of life is much more relaxed there and; you can get people to sign up without having to make a truly major full-time commitment to development. Nobody also expects 50 commits a year on a -stale branch, just 5 or 6 well-chosen ones, and even with part-time help, cvs can easily provide the requisite diffs to someone with a very specific point of focus (it's only you try to look at all of src between a branch that life starts sucking rocks). I also might not have said this 6 months ago when things like OpenSSL and RSA were not integrated and enhancing security really often did involve major infrastructural overhauls before you could address even some very basic security issue. We've gotten both far more functional and more modular as of late there, however, and it would certainly be my hope that future security fixes will generally be the easiest to merge without requiring interface changes or tons of infrastructural support to pull off (a buffer overflow or missing consistency check being a fairly stand-alone change, neh?). Or maybe I'm just smoking crack, but I honestly believe we have to at least try this. FreeBSD has really done some major growing up as OS in the last 3 years alone and I think we simply have to make periodic shifts in our MO to compensate or we're dogmeat. I'm also fine with your suggestion that we first try it for a few months to see how it truly goes before announcing the policy change to the world, but we should at least stop actively warning people away if we're going to try this at all seriously. We can be conservative and hold back on the horn-blowing without dire effect to this "experiment", but we can't have mixed messages going out without compromising it, either. > 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 To me, this is only an argument that you need more help, not that the fundamental idea of supporting security fixes for 3.x is somehow unsound. :-) It seems like you essentially agree in your next two paragraphs anyway, so can we now see a show of hands for "deputies" who'd be willing to work on back-porting even just security enhancements to 3.x (and, eventually, 4.x)? - Jordan 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?85378.970625261>