Is there a policy to delay & batch errata security alerts ?
Julian H. Stacey
jhs at berklix.com
Wed Sep 2 14:07:42 UTC 2015
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote:
> "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?
No. Not once they're researched & ready to publish. See below.
> > 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.
Sounds OK re 10.1, I had the impression over years there's
been flurries of announcements shortly after [some] releases.
> Besides, even if there were such a wave after each release, would it
> really matter?
Yes. It would suggest possible bad management &/or poor product, & bad press.
> 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.
OK, but for those supporting on a mix of stable + latest releases,
it's a wave of extra time consuming work.
> > 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?
No.
It was brief, expecting sensible extrapolation:
Management includes both asking people to work hard before a
release, and easing off a bit just after. Urgent issues could
continue to be solved, but researching longer existant less urgent
issues could be slackened for a bit, Without delay to publication
once complete.
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.
More information about the freebsd-security
mailing list