From owner-freebsd-security Thu Oct 5 11:24:55 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7BBB937B503; Thu, 5 Oct 2000 11:24:48 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id e95IOkK00529; Thu, 5 Oct 2000 12:24:47 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA00945; Thu, 5 Oct 2000 12:24:46 -0600 (MDT) Message-Id: <200010051824.MAA00945@harmony.village.org> To: Ralph Huntington Subject: Re: Stable branch Cc: developers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 05 Oct 2000 06:06:52 EDT." References: Date: Thu, 05 Oct 2000 12:24:46 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Ralph Huntington writes: : the latest release (not current), i.e., since 4.x-RELEASE is the latest, : then 3.x-STABLE hould be supported with bug fixes and security patches : until a 5.x-RELEASE is out. : : Does this seem unreasonable? -=r=- Yes and no. It sounds reasonable, but puts a significant burdon on the security officer and his security team to make it happen. Having two machines for -current and -stable is bad enough, plus test compiling patches on the last N RELEASES of -stable puts a fair load on getting an advisory out. Making that include a second branch will nearly double the work and pita factor to make it happen. When I was doing 4.0-current, 3.2-stable, 3.2-release, 3.1-release, 3.0-release, 2.2.8-release and 2.2.8-stable regression testing on a couple of kernel patches it took me a *HUGE* amount of time. 40% of it for 4.x and 3.x and 60% for the 2.2.8-stable and -release. Why so much for 2.x? the original author of the patch hadn't back ported it, was disinclined to back port it so I wound up doing it. This made it extremely painful to try to get the advisory out (I think it was 6 weeks from the time the bug hit -current until I sent the advisory out). Until you pay someone to do this full time, it isn't going to happen. History has shown this. This suggestion comes up every N years, we do OK with it for a couple of months until one bug comes along that's such a pain in the butt that we say "screw this old stuff, I'm just going to stop doing it because it is too much of a pita and no one seems to care enough to help." and then are happy for a while until we cut the next major branch in which case we recapitulate the whole process. Sorry to be such a sour puss, but I've "been there, tried that" before. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message