From owner-freebsd-security@freebsd.org Fri May 6 02:21:24 2016 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 578B7B2E214 for ; Fri, 6 May 2016 02:21:24 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D2711E22 for ; Fri, 6 May 2016 02:21:23 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-c6bff70000005f72-a1-572bffa11ac3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 98.1C.24434.1AFFB275; Thu, 5 May 2016 22:21:21 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u462LKJm006273; Thu, 5 May 2016 22:21:21 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u462LFpS005210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 May 2016 22:21:19 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u462LExj023345; Thu, 5 May 2016 22:21:14 -0400 (EDT) Date: Thu, 5 May 2016 22:21:14 -0400 (EDT) From: Benjamin Kaduk To: "Julian H. Stacey" cc: freebsd-security@freebsd.org Subject: Re: Batching errata & advisories in heaps degrades security. In-Reply-To: <201605051625.u45GPODc084944@fire.js.berklix.net> Message-ID: References: <201605051625.u45GPODc084944@fire.js.berklix.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixCmqrbvwv3a4QXOzqkXPpidsFnvWvmF3 YPL4d+MYm8eMT/NZApiiuGxSUnMyy1KL9O0SuDKu797FUrCOt+LFvansDYwHuboYOTgkBEwk HkxT7mLk4hASaGOSeHGnlR3C2cAo8efcWyYI5yCTxJ9HL1i7GDmBnHqJv73n2UBsFgEtiQ+X DoLZbAIqEjPfbASzRQQ0JF4degRmMwsoSLx/fJIJxBYWcJW4faaJGcTmFLCT6Phzlh3E5hVw lLjz6iU7yEVCArYSU5ZqgYRFBXQkVu+fwgJRIihxcuYTFoiRWhLLp29jmcAoMAtJahaS1AJG plWMsim5Vbq5iZk5xanJusXJiXl5qUW6Fnq5mSV6qSmlmxhB4cjuorqDcc5fr0OMAhyMSjy8 GSe1w4VYE8uKK3MPMUpyMCmJ8q76BxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwnsZJMebklhZ lVqUD5OS5mBREudlZGBgEBJITyxJzU5NLUgtgsnKcHAoSfC2gTQKFqWmp1akZeaUIKSZODhB hvMADc8CG15ckJhbnJkOkT/FqCglzrsTJCEAksgozYPrBaeL3UyqrxjFgV4R5lUFqeIBphq4 7ldAg5mABr+fqwkyuCQRISXVwFipxtEhtTlnte+MiJkKV0s3t3RUzGW2f/BSsDwgesKMA7ET 5Sdfbgt793X9pOTA8lQ7aZvOjNnnt1w9e69B4WjXCo5cAb0JPuseH/aUiNR9vSj/zJyNF3bm 2TexTRbeE5ShJBQhcL0xgWHuFkvDAK7pl3aJhc5dVBISxeWw4cuphwuf39FpVFFiKc5INNRi LipOBAB8LIsn8gIAAA== X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 02:21:24 -0000 On Thu, 5 May 2016, Julian H. Stacey wrote: > Benjamin Kaduk wrote: > > > As a member of the security team for two projects (not FreeBSD's, though), > > I can say that it is a lot of behind-the-scenes work to put out > > advisories, > > Of course. > > > and batching them reduces the unit cost of any given one. > > If so, their issue, not ours. Our concern is FreeBSD. The potential for burnout of secteam is of significant concern for FreeBSD. > > the > > contents of the errata notices have been public for quite some time > > URLs ? If info was complete early, delaying those announcement > degraded security of recipients. Batching also swamps recipients. My apologies; looking back at what I wrote it was not very clear. What I mean is that the patches for ENs are already public well before the EN announcement. The procedure for getting an EN approved is to first merge the patch to the relevant stable branch, and then ask for approval for an EN, with a pointer to the commit(s) in question. However, it is not necessarily public that a given change on the stable branch is going to qualify as an EN. So, when I said (in the trimmed part) that "affected parties [are] welcome to upgrade at their leisure", what I was trying to say was that if (e.g.) you have systems that were tripping over the ZFS memory leak from FreeBSD-EN-16:08.zfs, the patch you would need to fix it was already in public Subversion on stable/10 or stable/9 (the dates in question are listed in the EN). But it was not exactly publicized that this was a major issue meriting an EN; someone would probably have to watch the commit mail to see it. Sorry for the confusion, Ben