Date: Wed, 15 May 2019 22:52:47 -0400 From: Matt Garber <matt.garber@gmail.com> To: Bill Sorenson <instructionset@gmail.com> Cc: "Julian H. Stacey" <jhs@berklix.com>, Mel Pilgrim <list_freebsd@bluerosetech.com>, core@freebsd.org, hackers@freebsd.org, stable@freebsd.org Subject: Re: FreeBSD flood of 8 breakage announcements in 3 mins. Message-ID: <CANwXMPMyi96hFx-joD-ReZGYWO_P5KcRZnBu2C2j9QfJ-g1t_A@mail.gmail.com> In-Reply-To: <CACcTwYkr55Vxx-jk7uyhppT0LBxfKYDEzTxmhJLL-Se7EJVAew@mail.gmail.com> References: <201905151425.x4FEPNqk065975@fire.js.berklix.net> <e8125e97-6308-5ad0-b850-6825069683d4@bluerosetech.com> <CACcTwYkr55Vxx-jk7uyhppT0LBxfKYDEzTxmhJLL-Se7EJVAew@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 15, 2019 at 10:28 PM Bill Sorenson <instructionset@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANwXMPMyi96hFx-joD-ReZGYWO_P5KcRZnBu2C2j9QfJ-g1t_A>