freebsd security - May 2016 - Batching errata & advisories in heaps degrades security.

Benjamin Kaduk wrote:
> As a member of the security team for two projects (not FreeBSD's,
though),
> I can say that it is a lot of behind-the-scenes work to put out
> advisories,
Of course.
> and batching them reduces the unit cost of any given one.
If so, their issue, not ours.  Our concern is FreeBSD.

> the
> contents of the errata notices have been public for quite some time
URLs ? If info was complete early, delaying those announcement
degraded security of recipients. Batching also swamps recipients.

Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/
 Mail plain text,  No quoted-printable, HTML, base64, MS.doc.
 Prefix old lines '> '  Reply below old, like play script.  Break
lines by 80.
 Brexit: Meeting +UK blocks votes of Brits in EU  http://www.berklix.eu/brexit/

On 05/05/2016 17:25, Julian H. Stacey wrote:
> Benjamin Kaduk wrote:
>
>> As a member of the security team for two projects (not FreeBSD's,
though),
>> I can say that it is a lot of behind-the-scenes work to put out
>> advisories,
> Of course.
>
>> and batching them reduces the unit cost of any given one.
> If so, their issue, not ours.  Our concern is FreeBSD.
>
>
>> the
>> contents of the errata notices have been public for quite some time
> URLs ? If info was complete early, delaying those announcement
> degraded security of recipients. Batching also swamps recipients.
>
Totally the opposite, it means one rollout instead of X rollouts making 
it simpler not harder.

On Thu, 5 May 2016, Julian H. Stacey wrote:
> Benjamin Kaduk wrote:
>
> > As a member of the security team for two projects (not FreeBSD's,
though),
> > I can say that it is a lot of behind-the-scenes work to put out
> > advisories,
>
> Of course.
>
> > and batching them reduces the unit cost of any given one.
>
> If so, their issue, not ours.  Our concern is FreeBSD.
The potential for burnout of secteam is of significant concern for
FreeBSD.
> > the
> > contents of the errata notices have been public for quite some time
>
> URLs ? If info was complete early, delaying those announcement
> degraded security of recipients. Batching also swamps recipients.
My apologies; looking back at what I wrote it was not very clear.  What I
mean is that the patches for ENs are already public well before the EN
announcement.  The procedure for getting an EN approved is to first merge
the patch to the relevant stable branch, and then ask for approval for an
EN, with a pointer to the commit(s) in question.  However, it is not
necessarily public that a given change on the stable branch is going to
qualify as an EN.  So, when I said (in the trimmed part) that "affected
parties [are] welcome to upgrade at their leisure", what I was trying to
say was that if (e.g.) you have systems that were tripping over the ZFS
memory leak from FreeBSD-EN-16:08.zfs, the patch you would need to fix it
was already in public Subversion on stable/10 or stable/9 (the dates in
question are listed in the EN).  But it was not exactly publicized that
this was a major issue meriting an EN; someone would probably have to
watch the commit mail to see it.

Sorry for the confusion,

Ben