On 2019-05-15 7:25, Julian H. Stacey wrote:> Hi core@, > cc hackers@ & stable@ > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins." > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html > > Volunteers who contribute actual fixes are very much appreciated; > But those styled as 'management' who delay announcements to batch floods > damage us. As they've previously refused to stop, it's time to sack them. > > Just send each announcement out when ready, no delays to batch them. > No sys admins can deal with 8 in 3 mins: > Especially on multiple systems & releases. Recipients start > mitigating, then more flood in, & need review which are > most urgent to interrupt to; While also avoiding sudden upgrades > to many servers & releases, to minimise disturbing server users, > bosses & customers.Admins attentive to security issues will already be tracking CVEs for the software they use and mitigating or solving the vulnerability by all means available. By batching updates, FreeBSD is making administrative decisions for other people's systems. Some folks don't need to worry about scheduling 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 fixed 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. So 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 my exposure. Don't be Microsoft. Don't sit on security updates.
> Admins attentive to security issues will already be tracking CVEs for > the software they use and mitigating or solving the vulnerability by all > means available. > > By batching updates, FreeBSD is making administrative decisions for > other people's systems. Some folks don't need to worry about scheduling > 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 fixed > 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. So > 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 my > 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 whether 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.
Miroslav Lachman
2019-May-16 03:13 UTC
FreeBSD flood of 8 breakage announcements in 3 mins.
Mel Pilgrim wrote on 2019/05/16 02:30: [...]> By batching updates, FreeBSD is making administrative decisions for > other people's systems.? Some folks don't need to worry about scheduling > 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 fixed > 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.? So > 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 my > exposure. > > Don't be Microsoft. Don't sit on security updates.+1 Delaying / hiding security updates cannot be good. The vulnerability already exists. Delayed updates do favor to "bad persons", not sysadmins. Even information about found vulnerability is more valuable for sysadmins than silence. Some vulnerabilities can be mitigated by configuration changes or some service replacement (eg. ntpd). But if I don't know that there is some vulnerability I cannot do anything. It would also be good if base system vulnerabilities are first published in FreeBSD vuxml. Then it can be reported to sysadmins by package security/base-audit. None of these recent Sec. Advisories are listed in Vuxml yet! It's bad example of not dog fooding there. I am not saying that FreeBSD SO do bad work. I really appreciate it. But there is still something to improve. Kind regards Miroslav Lachman