Is there a policy to delay & batch errata security alerts ?
Dag-Erling Smørgrav
des at des.no
Wed Sep 2 07:29:42 UTC 2015
"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
More information about the freebsd-security
mailing list