freebsd security - Sep 2015 - Is there a policy to delay & batch errata security alerts ?

On Sat, 29 Aug 2015, Julian H. Stacey wrote:
> Presumably there's no delays eg for PR, giving longer quiet periods
before
> a release, slipping out bad news immediately after good.
That seems highly unlikely.
> What else might be causing batch flooding of alerts ?
It's an awful lot of work to actually put all the pieces together to
release security advisories; batching reduces the workload for the team.
This is true no matter what project you look at, be it FreeBSD or MIT
Kerberos (where I am on the security team and can speak from personal
experience) or something else.  This is why errata notices are delayed
until they can go out with a security advisory; it's explicitly a way to
reduce the workload on the security team.

-Ben Kaduk

Hi,
Benjamin Kaduk wrote:
> On Sat, 29 Aug 2015, Julian H. Stacey wrote:
> 
> > Presumably there's no delays eg for PR, giving longer quiet
periods before
> > a release, slipping out bad news immediately after good.
> 
> That seems highly unlikely.
Hope so. Just considering what might add to floods.
> > What else might be causing batch flooding of alerts ?
> 
> It's an awful lot of work to actually put all the pieces together to
> release security advisories;
Sure, realised :-)
> batching reduces the workload for the team.
Batching for a common lib or tool, Yes.
But alerting pre existing issues just after new releases will
reduce security for all who can't spare enough time, so must skip the flood.
> This is true no matter what project you look at, be it FreeBSD or MIT
> Kerberos (where I am on the security team and can speak from personal
> experience) or something else.  This is why errata notices are delayed
> until they can go out with a security advisory; it's explicitly a way
to
> reduce the workload on the security team.
There were 5 Errata & 3 Advisories with
	Sender: owner-freebsd-announce at freebsd.org
after 13 Aug 2015 announcement of 10.2-RELEASE.

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Reply after previous text, like a play - Not before, which looses context.
 Indent previous text with "> "         Insert new lines before 80
chars.
 Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64.
 Subsidise contraception V. Global warming, pollution, famine, migration.

"Julian H. Stacey" <jhs at berklix.com>
writes:
> But alerting pre existing issues just after new releases will reduce
> security for all who can't spare enough time, so must skip the flood.
We can't always hold back a release, even when there are known issues.
Users are waiting for it, release engineers need to move on to other
work, and the very fact that we're holding it back with no explanation
and no visible activity tells people that something is up.  Also, how
long are we going to hold it?  There is *never* a point in time where
the security team does not know of or suspect at least one issue in a
current or upcoming release.  The line has to be drawn somewhere.  In
the case of 10.2, the three ENs published on 2015-08-18 were for issues
that would only affect a very small minority of users, and the expat
issue was not raised until the release was almost complete.  The ENs and
SAs published on 2015-08-25 were either unknown or still in the very
early investigation phase at the time of the release.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no