From owner-freebsd-security  Wed Nov 22  7: 7:46 2000
Delivered-To: freebsd-security@freebsd.org
Received: from spammie.svbug.com (mg134-015.ricochet.net [204.179.134.15])
	by hub.freebsd.org (Postfix) with ESMTP
	id DF3DF37B4D7; Wed, 22 Nov 2000 07:07:29 -0800 (PST)
Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1])
	by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id HAA00642;
	Wed, 22 Nov 2000 07:06:34 -0800 (PST)
	(envelope-from jessem@spammie.svbug.com)
Message-Id: <200011221506.HAA00642@spammie.svbug.com>
Date: Wed, 22 Nov 2000 07:06:32 -0800 (PST)
From: opentrax@email.com
Reply-To: opentrax@email.com
Subject: Re: New security policy for FreeBSD 3.x 
To: imp@village.org
Cc: security-officer@FreeBSD.ORG, arch@FreeBSD.ORG
In-Reply-To: <200011220624.XAA40393@harmony.village.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org



On 21 Nov, Warner Losh wrote:
> In message <200011211843.KAA00298@spammie.svbug.com> opentrax@email.com writes:
> : Please note I've cc'd to arch. Could you make  your
> : comments there?
> : 
> : On 19 Nov, FreeBSD Security Advisories wrote:
> : > -----BEGIN PGP SIGNED MESSAGE-----
> : > 
> : > The FreeBSD Security Officer would like to announce a change in policy
> : > regarding security support for the FreeBSD 3.x branch.
> : > 
> : > Due to the frequent difficulties encountered in fixing the old code
> : > contained in FreeBSD 3.x, we will no longer be requiring security
> : > problems to be fixed in that branch prior to the release of an
> : > advisory that also pertains to FreeBSD 4.x.  In recent months this
> : > requirement has led to delays in the release of advisories, which
> : > negatively impacts users of the current FreeBSD release branch
> : > (FreeBSD 4.x).
> : > 
> : Could you clarify exactly what you are saying? It's not clear.
> : Perhaps a chart might help.
> 
> [[ included original text to give context ]]
> 
> Generally speaking, fixes go into -current first, then are MFC to
> 4.x-stable and then MFC to 3.x-stable.  Sometimes the MFC is easy
> (when the code is substantially identical) and sometimes it isn't.  In
> the cases it isn't, we won't hold up the advisory for a 3.x fix.  We
> will inform select interested and sufficiently clueful parties of
> pending advisories for which no 3.x solution is available.  If they
> can get us a fix for 3.x before we release our advisory (usually a few
> days to a week depending on its severity and other factors), we will
> include it in the advisory.  If not, then the advisory goes out anyway
> without a 3.x fix, with the usual room for negotiation for reasonable
> extensions.
> 
> In other words, fixes for 3.x will no longer gate security
> advisories, but will be included if available.
> 
Thank you for taking the time to explain this Warner.
The original advisory was not as clear. However, I still fell
a bit confused. As such, I would like to write a document that
would explain this situation. This document would include
a chart to help those that might need assitance (like me).

I beleive that such a document would prove useful and would
help the security-officer by providing a definitive 
document that could be pointed to. This document could also
be included in future advisories, where needed.

Let me say lastly that my first impression of this 'advisory'
was not what you said, thereby leading to my confusion.
Since I believe it clear, I would then suggest the aforementioned
document which I am willing to collect/author/edit.

				best regards,
				Jessem.





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