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

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

"Julian H. Stacey" <jhs at berklix.com>
writes:
> I wasn't suggesting delaying releases, just how to smooth down alert
> waves after releases.
So you're suggesting holding back advisories?
> 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.
Not more than usual.  There just happened to be a cluster immediately
after 10.2.  There was no such cluster after 10.1; three advisories were
published four weeks after the release and a fourth a week after that.

Besides, even if there were such a wave after each release, would it
really matter?  Most organizational users need weeks if not months to
test a new version and plan its deployment, so that hypothetical wave
would not affect them any more than any other batch of advisories.
> 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 ?
You want the security team to take a vacation after each release so we
can maintain the illusion, at least for a couple of weeks, that there
are no bugs or vulnerabilities in FreeBSD?

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