From owner-freebsd-stable@freebsd.org Thu May 16 02:53:00 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E37AF15AA30E for ; Thu, 16 May 2019 02:52:59 +0000 (UTC) (envelope-from matt.garber@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C53E84F2F for ; Thu, 16 May 2019 02:52:59 +0000 (UTC) (envelope-from matt.garber@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 09EB915AA30D; Thu, 16 May 2019 02:52:59 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D97E115AA30B; Thu, 16 May 2019 02:52:58 +0000 (UTC) (envelope-from matt.garber@gmail.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BB5E84F23; Thu, 16 May 2019 02:52:58 +0000 (UTC) (envelope-from matt.garber@gmail.com) Received: by mail-qt1-x82c.google.com with SMTP id d13so2234490qth.5; Wed, 15 May 2019 19:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O1k/hdGvverXmfo/LcfqRE2On8EaDRUEEDoqpA+503c=; b=fBbWbUs3or66X3yu9LW0m0KF6xYQzXMrm9GkRW/YX3vrEl8sPnKPzmNbon8n1OqxwV GycF5ZJjNg7MEZD4IUfF2H6g069oRxCDRaE/+14xu/5XDe5+6YSVxSCQv3OvTBBp33Qh KtvuIh/ovS2OgqnFdqBQQsHjyXCQKd14gtM+ebg6L+EBqbDWQjAMKmr6Tw0EuYCrQ5D9 BdQKGqd7f/t5pDCwFg8f11+wf1mdhyiOvBain8VmG81cTKsJAwtNvPhC9E4MfeaJxjid hZUCk84V6cvNnueyjt7q5tZNefI+047Ui4u2IO+GsJUx5Yt2wOPiEBhzd6uSHGpGDzI5 IdKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O1k/hdGvverXmfo/LcfqRE2On8EaDRUEEDoqpA+503c=; b=tolmfI5afI+l6cppzI9ADeJF4LqFiCzMzhY3PupCgqJuPdUyD2+3XrxGpFcXV0M6cI 0MGML96/rnERn87keqH+pfImWNi90hm2NNZN/CTmpZNXfvEK85zTiJcqIbcMg3lZH0jd uhrYeCXeBM/ZC/eh+Z41t5g8gSvvrIabAqV3yFPViFdqPXE4HPCBzbj9Aoo//89OlFkm eNq9hXPl7QBFq1sOTdce7Abj7P8KJjGjPa+fW00Ox7pCZ+MVv0TDSWlf2DrwuKHtuny4 ZUpIUMfFx1k6+srWkFp02x5D6mrWfwOVaey2qKze7VpGzhfHumSexDhNDSsfvXUjLXGR igeA== X-Gm-Message-State: APjAAAXJWcRxVCpUGD7MCMscpxMKUp0764D5d8XgnKmuhDuzF4EPumOX 90N5nj1VWsibUQEvhmswUsB6keLW9sI/GJfGWn8= X-Google-Smtp-Source: APXvYqxhD43BDwic9gN2kZgMcZb0UWbONCUDXyeCfe7vK27wkuCW6hKV9GXtJ07CeUKvPtHR0keuC25Rw26TVkYiDI8= X-Received: by 2002:a0c:9350:: with SMTP id e16mr35026920qve.119.1557975178032; Wed, 15 May 2019 19:52:58 -0700 (PDT) MIME-Version: 1.0 References: <201905151425.x4FEPNqk065975@fire.js.berklix.net> In-Reply-To: From: Matt Garber Date: Wed, 15 May 2019 22:52:47 -0400 Message-ID: Subject: Re: FreeBSD flood of 8 breakage announcements in 3 mins. To: Bill Sorenson Cc: "Julian H. Stacey" , Mel Pilgrim , core@freebsd.org, hackers@freebsd.org, stable@freebsd.org X-Rspamd-Queue-Id: 7BB5E84F23 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.965,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 02:53:00 -0000 On Wed, May 15, 2019 at 10:28 PM Bill Sorenson wrote: > > Admins attentive to security issues will already be tracking CVEs for > > the software they use and mitigating or solving the vulnerability by al= l > > means available. > > > > By batching updates, FreeBSD is making administrative decisions for > > other people's systems. Some folks don't need to worry about schedulin= g > > downtime and will benefit from faster update availability. Folks who > > need to worry about scheduling downtime are already going to batch > > updates and should be allowed to make those decisions for themselves. > > Batched SAs help in neither case. > > > > Example: the ntpd CVE is more than two months old, and was rapidly fixe= d > > in ports. I was able to switch my systems to the ports ntpd during a > > scheduled downtime window in March instead of doing it this weekend. S= o > > not only did I benefit from the faster update availability, I was able > > to make my own decision about my own systems and significantly reduce m= y > > exposure. > > > > Don't be Microsoft. Don't sit on security updates. > > I'm inclined to agree with this sentiment. I can sort of understand > holding a SA > for a week while waiting for another SA's embargo to end but beyond that = I > think > the patches for Security Advisories should be made available as soon as > practical. SysAdmins need to be smart enough to plan updating strategies, > whether they can get away with patching quarterly, monthly, weekly, > immediately, > etc. It depends on the systems and the circumstances. I appreciate the SO= 's > work, but in my opinion if a patch to a CVE makes it to STABLE it should > be in > the patch branch within a week or so unless issues are discovered (and > depending > on the severity of the issue maybe it should be pushed anyway with > caveats.) > > FreeBSD already makes a distinction between SAs and Errata unlike some > other > projects, I think that should factor into how they are delivered. > Security Advisories should be made available quickly regardless of whethe= r > they > are known the be exploited in the wild or we might as well just go the > Linux > route and call everything a 'bug fix' and not bother categorizing things > at all. I=E2=80=99m certainly not advocating holding on to SAs for an extended peri= od of time, either: if something like the ntpd fix takes a long time to roll out on a consistent basis, maybe that=E2=80=99s rationale for the separate disc= ussion of further shrinking the base system (?), since what=E2=80=99s =E2=80=98bes= t=E2=80=99 for the majority of users in that scenario is probably getting that patched via packages/ports in days, not weeks (or months). However, I otherwise don=E2=80=99t find anything objectionable to releasing= several ENs or SAs at once, assuming they were close in time anyway. E.g., I think it=E2=80=99s perfectly sane to publish 4-5 advisories/notices at once on a = Thursday rather than one on Monday, one on Tuesday, two on Wednesday, etc., especially since we don=E2=80=99t yet have pkg base, and it fits the model = of RELEASE-pX to RELEASE-pY bundling those up. I=E2=80=99m not sure what you meant about Linux distros not categorizing fi= xes, though =E2=80=94 with some notable exceptions, most of the big ones certain= ly tag security fixes separately, which is what allows `unattended-upgrades` on Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely automatically as scheduled on *only* security errata, while leaving all other types of updates alone for admin intervention. =E2=80=94 Matt