From owner-freebsd-security@freebsd.org Wed Sep 2 14:07:42 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08CC39C8E3E for ; Wed, 2 Sep 2015 14:07:42 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86E9BFE2 for ; Wed, 2 Sep 2015 14:07:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5083CE4E.dip0.t-ipconnect.de [80.131.206.78]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t82EBIb0026246; Wed, 2 Sep 2015 16:11:19 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t82E7YeU035617; Wed, 2 Sep 2015 16:07:34 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t82E7AaX003325; Wed, 2 Sep 2015 16:07:22 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201509021407.t82E7AaX003325@fire.js.berklix.net> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= cc: Benjamin Kaduk , freebsd-security@freebsd.org Subject: Re: Is there a policy to delay & batch errata security alerts ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 02 Sep 2015 09:29:38 +0200." <86vbbtcm8t.fsf@nine.des.no> Date: Wed, 02 Sep 2015 16:07:10 +0200 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:07:42 -0000 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: > "Julian H. Stacey" writes: > > I wasn't suggesting delaying releases, just how to smooth down alert > > waves after releases. > > So you're suggesting holding back advisories? No. Not once they're researched & ready to publish. See below. > > But I had forgotten inevitably some issues that people worked hard on > > to meet releases, will just miss, & often continue to be worked hard > > on, so more than usual is ready to be announced just after release. > > Not more than usual. There just happened to be a cluster immediately > after 10.2. There was no such cluster after 10.1; three advisories were > published four weeks after the release and a fourth a week after that. Sounds OK re 10.1, I had the impression over years there's been flurries of announcements shortly after [some] releases. > Besides, even if there were such a wave after each release, would it > really matter? Yes. It would suggest possible bad management &/or poor product, & bad press. > Most organizational users need weeks if not months to > test a new version and plan its deployment, so that hypothetical wave > would not affect them any more than any other batch of advisories. OK, but for those supporting on a mix of stable + latest releases, it's a wave of extra time consuming work. > > Perhaps if core@ extend their presumed per release Thank You notes > > to re@ & beyond "Thanks for rolling a release", & append "Please > > take a short break, you deserve it + it will help minimise an > > immediate post release notification wave". Might that help ? > > You want the security team to take a vacation after each release so we > can maintain the illusion, at least for a couple of weeks, that there > are no bugs or vulnerabilities in FreeBSD? No. It was brief, expecting sensible extrapolation: Management includes both asking people to work hard before a release, and easing off a bit just after. Urgent issues could continue to be solved, but researching longer existant less urgent issues could be slackened for a bit, Without delay to publication once complete. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. Subsidise contraception V. Global warming, pollution, famine, migration.