Batching errata & advisories in heaps degrades security.

[Eric van Gyzen]

Julian suggested that I share our private conversation:

Eric wrote:
> Regardless of my opinion on the topic, three of these are errata with no
> security implications, so the argument doesn't really apply in this context.

Julian wrote:

> Thanks Eric, fair point.  So some of my argument doesnt apply,
> better for FreeBSD than I thought. :-)  Still batching is bad,
> just not as bad as I thought, but still 3 errata swamp the security post.


On 05/05/2016 09:59, Julian H. Stacey wrote:
> Another bunch of Security alerts, degrades FreeBSD by being clumped together:
>
>   Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-16:17.openssl
>   Date: Wed,  4 May 2016 22:55:46 +0000 (UTC)
>   
>   Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-16:06.libc
>   Date: Wed,  4 May 2016 22:56:31 +0000 (UTC)
>   
>   Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-16:08.zfs
>   Date: Wed,  4 May 2016 22:56:40 +0000 (UTC)
>   
>   Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-16:07.ipi
>   Date: Wed,  4 May 2016 22:56:35 +0000 (UTC)
>
> I guess many recipients get tired of recent indigestable batches of 
> multiple FreeBSD Errata & think approx:
>
>   _Why_ have they been artificially batching in last years ?
>   I could spare time to interrupt work for one priority alert,
>   Not for a heap batched seconds apart ! _Why_ ?!
>   I have no time now to action all this heap ! Maybe later ...
>     ( & meanwhile security @ FreeBSD could complacently think:
>     "We published all 4, if you don't immediately find time to 
>      secure all 4 & someone abuses you, don't blame us !" )
>   Are they batched in delusion it will help FreeBSD public relations,
>   to not scare people with too many days with FreeBSD alerts ?
>   Batching _Degrades_ security.  It is bad over-management,
>   FreeBSD was better previously without batching, publishing each
>   problem when analysed, Not held back for batching.
>
> Cheers,
> Julian