Is there a policy to delay & batch errata security alerts ?

[Julian H. Stacey]

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.