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

"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

=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote:
> "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.
Thanks DES,
I wasn't suggesting delaying releases, just how to smooth down alert
waves after releases.  But I had forgotten inevitably some issues
that people worked hard on to meet releases, will just miss, & often
continue to be worked hard on, so more than usual is ready to be
announced just after release.

Perhaps if core@ extend their presumed per release Thank You notes
to re@ & beyond "Thanks for rolling a release", & append
"Please
take a short break, you deserve it + it will help minimise an
immediate post release notification wave".  Might that help ?

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.