Batching errata & advisories in heaps degrades security.

[Julian H. Stacey]

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
--
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/
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Benjamin Kaduk]

On Thu, 5 May 2016, Julian H. Stacey wrote:

> Another bunch of Security alerts, degrades FreeBSD by being clumped together:
>

> I guess many recipients get tired of recent indigestable batches of
> multiple FreeBSD Errata & think approx:

I cannot recall whether you were participating in the discussion the last
time this topic came up. Regardless, it feels like it was somewhat recent
(a year or so).

> _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.

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, and batching them reduces the unit cost of any given one.

I further note that this recent batch that you are complaining about,
contained only one security advisory and three errata notices; the
contents of the errata notices have been public for quite some time, and
affected parties welcome to upgrade at their leisure [manually, without
freebsd-update, of course].

We can perhaps agree to disagree about whether the batching is good, but I
do not see much value in rehashing the same arguments periodically.

-Ben

[Julian H. Stacey]

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/

[Steven Hartland]

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.

[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

[Roger Marquis]

> Totally the opposite, it means one rollout instead of X rollouts making it
> simpler not harder.

I don't know, isn't that the logic behind Microsoft's failed
patch-Tuesdays?

It's important not to confound security with usability. Any delay to a
security advisory is an invitation to hackers. I don't think that's
what end-users expect from FreeBSD much as the long arm of the NSA might
want to make it so (primarily vis-a-vis CERT and NIST).

Those sites that don't care about security are well served by batching
but given the packaging of base it seems like there's no longer any
significant benefit.

Roger

[Benjamin Kaduk]

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