freebsd stable - May 2019 - FreeBSD flood of 8 breakage announcements in 3 mins.

> 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.

On Wed, May 15, 2019 at 10:28 PM Bill Sorenson <instructionset at
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
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.

I?m certainly not advocating holding on to SAs for an extended period of
time, either: if something like the ntpd fix takes a long time to roll out
on a consistent basis, maybe that?s rationale for the separate discussion
of further shrinking the base system (?), since what?s ?best? 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?t find anything objectionable to releasing several
ENs or SAs at once, assuming they were close in time anyway. E.g., I think
it?s 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?t yet have pkg base, and it fits the model of
RELEASE-pX to RELEASE-pY bundling those up.

I?m not sure what you meant about Linux distros not categorizing fixes,
though ? with some notable exceptions, most of the big ones certainly 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.


?
Matt