Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Charles Sprickman via freebsd-stable]

> On May 16, 2019, at 5:41 AM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Alan Somers wrote on 2019/05/16 05:16:
>> On Wed, May 15, 2019 at 9:14 PM Miroslav Lachman <000.f...@quip.cz> wrote:
> 
>>> It would also be good if base system vulnerabilities are first published
>>> in FreeBSD vuxml. Then it can be reported to sysadmins by package
>>> security/base-audit.
>> +1.  Reporting base + ports vulnerabilities in a common way would be
>> great.  I assume that this is already part of the pkgbase project
>> being worked on by brd and others.
> 
> The functionality is already there. The only part missing is Security Office 
> should fill the data in to vuxml at the time of publishing new SA.
> 
> Thanks to Mark Felder 
> https://blog.feld.me/posts/2016/08/monitoring-freebsd-base-system-vulnerabilities-with-pkg-audit/
> Then I provided periodic script 
> https://www.freshports.org/security/base-audit/ 
> 

There’s also this as a “right now” solution if you use nagios:

https://github.com/frlen/nagios-plugins/blob/master/check_freebsd_version 


You do have to adjust it to check only once or twice a day and to provide for a 
large number of retries, as the remote portion of the check to find the current 
version often times out.

Thanks,

Charles

> Miroslav Lachman
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Miroslav Lachman]

Alan Somers wrote on 2019/05/16 05:16:

On Wed, May 15, 2019 at 9:14 PM Miroslav Lachman <000.f...@quip.cz> wrote:



It would also be good if base system vulnerabilities are first published
in FreeBSD vuxml. Then it can be reported to sysadmins by package
security/base-audit.


+1.  Reporting base + ports vulnerabilities in a common way would be
great.  I assume that this is already part of the pkgbase project
being worked on by brd and others.


The functionality is already there. The only part missing is Security 
Office should fill the data in to vuxml at the time of publishing new SA.


Thanks to Mark Felder 
https://blog.feld.me/posts/2016/08/monitoring-freebsd-base-system-vulnerabilities-with-pkg-audit/
Then I provided periodic script 
https://www.freshports.org/security/base-audit/


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Matt Garber]

On Wed, May 15, 2019 at 11:15 PM Bill Sorenson 
wrote:

> > I’m not sure what you meant about Linux distros not categorizing fixes,
> though — with some notable exceptions, most of the big ones certainly tag
> security fixes >separately, which is what allows `unattended-upgrades` on
> Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely
> automatically as scheduled on > *only* security errata, while leaving all
> other types of updates alone for admin intervention.
>
> My comment about Linux was not in regards to any particular distro, they
> all
> have interesting policies of varying effectiveness when it comes to release
> engineering, but specifically about the Linux kernel team (Torvalds Et al,)
> which last I checked had a policy of specifically not handling security
> issues
> any different from any generic bug. Distros may do their own kernel release
> engineering and handling that themselves which is fine.


Understood, yep, that historical stance in the kernel itself has really
sucked and does no one any favors with ‘everything is just a bug.’
Thankfully the kernel self-protection project has made some significant
strides in that area, even if the overall security attitude of maintainers
has been slower to positive change than would be ideal.


—
Matt
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Bill Sorenson]

> I’m not sure what you meant about Linux distros not categorizing fixes, 
> though — with some notable exceptions, most of the big ones certainly tag 
> security fixes >separately, which is what allows `unattended-upgrades` on 
> Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely 
> automatically as scheduled on > *only* security errata, while leaving all 
> other types of updates alone for admin intervention.

My comment about Linux was not in regards to any particular distro, they all
have interesting policies of varying effectiveness when it comes to release
engineering, but specifically about the Linux kernel team (Torvalds Et al,)
which last I checked had a policy of specifically not handling security issues
any different from any generic bug. Distros may do their own kernel release
engineering and handling that themselves which is fine.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Alan Somers]

On Wed, May 15, 2019 at 9:14 PM Miroslav Lachman <000.f...@quip.cz> wrote:
>
> Mel Pilgrim wrote on 2019/05/16 02:30:
>
> [...]
>
> > By batching updates, FreeBSD is making administrative decisions for
> > other people's systems.  Some folks don't need to worry about scheduling
> > downtime and will benefit from faster update availability.  Folks who
> > need to worry about scheduling downtime are already going to batch
> > updates and should be allowed to make those decisions for themselves.
> > Batched SAs help in neither case.
> >
> > Example: the ntpd CVE is more than two months old, and was rapidly fixed
> > in ports.  I was able to switch my systems to the ports ntpd during a
> > scheduled downtime window in March instead of doing it this weekend.  So
> > not only did I benefit from the faster update availability, I was able
> > to make my own decision about my own systems and significantly reduce my
> > exposure.
> >
> > Don't be Microsoft. Don't sit on security updates.
>
> +1
>
> Delaying / hiding security updates cannot be good. The vulnerability
> already exists. Delayed updates do favor to "bad persons", not
> sysadmins. Even information about found vulnerability is more valuable
> for sysadmins than silence. Some vulnerabilities can be mitigated by
> configuration changes or some service replacement (eg. ntpd). But if I
> don't know that there is some vulnerability I cannot do anything.
>
> It would also be good if base system vulnerabilities are first published
> in FreeBSD vuxml. Then it can be reported to sysadmins by package
> security/base-audit.

+1.  Reporting base + ports vulnerabilities in a common way would be
great.  I assume that this is already part of the pkgbase project
being worked on by brd and others.

>
> None of these recent Sec. Advisories are listed in Vuxml yet! It's bad
> example of not dog fooding there.
>
> I am not saying that FreeBSD SO do bad work. I really appreciate it. But
> there is still something to improve.
>
> Kind regards
> Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Miroslav Lachman]

Mel Pilgrim wrote on 2019/05/16 02:30:

[...]

By batching updates, FreeBSD is making administrative decisions for 
other people's systems.  Some folks don't need to worry about scheduling 
downtime and will benefit from faster update availability.  Folks who 
need to worry about scheduling downtime are already going to batch 
updates and should be allowed to make those decisions for themselves. 
Batched SAs help in neither case.


Example: the ntpd CVE is more than two months old, and was rapidly fixed 
in ports.  I was able to switch my systems to the ports ntpd during a 
scheduled downtime window in March instead of doing it this weekend.  So 
not only did I benefit from the faster update availability, I was able 
to make my own decision about my own systems and significantly reduce my 
exposure.


Don't be Microsoft. Don't sit on security updates.


+1

Delaying / hiding security updates cannot be good. The vulnerability 
already exists. Delayed updates do favor to "bad persons", not 
sysadmins. Even information about found vulnerability is more valuable 
for sysadmins than silence. Some vulnerabilities can be mitigated by 
configuration changes or some service replacement (eg. ntpd). But if I 
don't know that there is some vulnerability I cannot do anything.


It would also be good if base system vulnerabilities are first published 
in FreeBSD vuxml. Then it can be reported to sysadmins by package 
security/base-audit.


None of these recent Sec. Advisories are listed in Vuxml yet! It's bad 
example of not dog fooding there.


I am not saying that FreeBSD SO do bad work. I really appreciate it. But 
there is still something to improve.


Kind regards
Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Matt Garber]

On Wed, May 15, 2019 at 10:28 PM Bill Sorenson 
wrote:

> > Admins attentive to security issues will already be tracking CVEs for
> > the software they use and mitigating or solving the vulnerability by all
> > means available.
> >
> > By batching updates, FreeBSD is making administrative decisions for
> > other people's systems.  Some folks don't need to worry about scheduling
> > downtime and will benefit from faster update availability.  Folks who
> > need to worry about scheduling downtime are already going to batch
> > updates and should be allowed to make those decisions for themselves.
> > Batched SAs help in neither case.
> >
> > Example: the ntpd CVE is more than two months old, and was rapidly fixed
> > in ports.  I was able to switch my systems to the ports ntpd during a
> > scheduled downtime window in March instead of doing it this weekend.  So
> > not only did I benefit from the faster update availability, I was able
> > to make my own decision about my own systems and significantly reduce my
> > exposure.
> >
> > Don't be Microsoft. Don't sit on security updates.
>
> I'm inclined to agree with this sentiment. I can sort of understand
> holding a SA
> for a week while waiting for another SA's embargo to end but beyond that I
> think
> the patches for Security Advisories should be made available as soon as
> practical. SysAdmins need to be smart enough to plan updating strategies,
> whether they can get away with patching quarterly, monthly, weekly,
> immediately,
> etc. It depends on the systems and the circumstances. I appreciate the SO's
> work, but in my opinion if a patch to a CVE makes it to STABLE it should
> be in
> the patch branch within a week or so unless issues are discovered (and
> depending
> on the severity of the issue maybe it should be pushed anyway with
> caveats.)
>
> FreeBSD already makes a distinction between SAs and Errata unlike some
> other
> projects, I think that should factor into how they are delivered.
> Security Advisories should be made available quickly regardless of whether
> they
> are known the be exploited in the wild or we might as well just go the
> Linux
> route and call everything a 'bug fix' and not bother categorizing things
> at all.


I’m certainly not advocating holding on to SAs for an extended period of
time, either: if something like the ntpd fix takes a long time to roll out
on a consistent basis, maybe that’s rationale for the separate discussion
of further shrinking the base system (?), since what’s ‘best’ for the
majority of users in that scenario is probably getting that patched via
packages/ports in days, not weeks (or months).

However, I otherwise don’t find anything objectionable to releasing several
ENs or SAs at once, assuming they were close in time anyway. E.g., I think
it’s perfectly sane to publish 4-5 advisories/notices at once on a Thursday
rather than one on Monday, one on Tuesday, two on Wednesday, etc.,
especially since we don’t yet have pkg base, and it fits the model of
RELEASE-pX to RELEASE-pY bundling those up.

I’m not sure what you meant about Linux distros not categorizing fixes,
though — with some notable exceptions, most of the big ones certainly tag
security fixes separately, which is what allows `unattended-upgrades` on
Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely
automatically as scheduled on *only* security errata, while leaving all
other types of updates alone for admin intervention.


—
Matt
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Bill Sorenson]

> Admins attentive to security issues will already be tracking CVEs for
> the software they use and mitigating or solving the vulnerability by all
> means available.
>
> By batching updates, FreeBSD is making administrative decisions for
> other people's systems.  Some folks don't need to worry about scheduling
> downtime and will benefit from faster update availability.  Folks who
> need to worry about scheduling downtime are already going to batch
> updates and should be allowed to make those decisions for themselves.
> Batched SAs help in neither case.
>
> Example: the ntpd CVE is more than two months old, and was rapidly fixed
> in ports.  I was able to switch my systems to the ports ntpd during a
> scheduled downtime window in March instead of doing it this weekend.  So
> not only did I benefit from the faster update availability, I was able
> to make my own decision about my own systems and significantly reduce my
> exposure.
>
> Don't be Microsoft. Don't sit on security updates.

I'm inclined to agree with this sentiment. I can sort of understand holding a SA
for a week while waiting for another SA's embargo to end but beyond that I think
the patches for Security Advisories should be made available as soon as
practical. SysAdmins need to be smart enough to plan updating strategies,
whether they can get away with patching quarterly, monthly, weekly, immediately,
etc. It depends on the systems and the circumstances. I appreciate the SO's
work, but in my opinion if a patch to a CVE makes it to STABLE it should be in
the patch branch within a week or so unless issues are discovered (and depending
on the severity of the issue maybe it should be pushed anyway with caveats.)

FreeBSD already makes a distinction between SAs and Errata unlike some other
projects, I think that should factor into how they are delivered.
Security Advisories should be made available quickly regardless of whether they
are known the be exploited in the wild or we might as well just go the Linux
route and call everything a 'bug fix' and not bother categorizing things at all.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Mel Pilgrim]

On 2019-05-15 7:25, Julian H. Stacey wrote:

Hi core@,
cc hackers@ & stable@

PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."

https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html

Volunteers who contribute actual fixes are very much appreciated;
But those styled as 'management' who delay announcements to batch floods
damage us. As they've previously refused to stop, it's time to sack them.

Just send each announcement out when ready, no delays to batch them.
No sys admins can deal with 8 in 3 mins:
   Especially on multiple systems & releases.  Recipients start
   mitigating, then more flood in, & need review which are
   most urgent to interrupt to;  While also avoiding sudden upgrades
   to many servers & releases, to minimise disturbing server users,
   bosses & customers.


Admins attentive to security issues will already be tracking CVEs for 
the software they use and mitigating or solving the vulnerability by all 
means available.


By batching updates, FreeBSD is making administrative decisions for 
other people's systems.  Some folks don't need to worry about scheduling 
downtime and will benefit from faster update availability.  Folks who 
need to worry about scheduling downtime are already going to batch 
updates and should be allowed to make those decisions for themselves. 
Batched SAs help in neither case.


Example: the ntpd CVE is more than two months old, and was rapidly fixed 
in ports.  I was able to switch my systems to the ports ntpd during a 
scheduled downtime window in March instead of doing it this weekend.  So 
not only did I benefit from the faster update availability, I was able 
to make my own decision about my own systems and significantly reduce my 
exposure.


Don't be Microsoft. Don't sit on security updates.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Steven Hartland]

Is disagree, having them hatched causes us less work not more, as others
have said one update not many, which result in one outage of systems that
need patching not many.

   Regards
   Steve

On Wed, 15 May 2019 at 16:48, Julian H. Stacey  wrote:

> Hi, Reference:
> > From: Alan Somers 
> > Date: Wed, 15 May 2019 08:32:26 -0600
>
> Alan Somers wrote:
> > On Wed, May 15, 2019 at 8:26 AM Julian H. Stacey 
> wrote:
> > >
> > > Hi core@,
> > > cc hackers@ & stable@
> > >
> > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."
> > >
> > >
> https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html
> > >
> > > Volunteers who contribute actual fixes are very much appreciated;
> > > But those styled as 'management' who delay announcements to batch
> floods
> > > damage us. As they've previously refused to stop, it's time to sack
> them.
> > >
> > > Just send each announcement out when ready, no delays to batch them.
> > > No sys admins can deal with 8 in 3 mins:
> > >   Especially on multiple systems & releases.  Recipients start
> > >   mitigating, then more flood in, & need review which are
> > >   most urgent to interrupt to;  While also avoiding sudden upgrades
> > >   to many servers & releases, to minimise disturbing server users,
> > >   bosses & customers.
> > >
> > > Cheers,
> > > Julian
> > > --
> > > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich
> Aachen Kent
> > >  http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in
> EU.
> > >  Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers
> died.
> >
> > I disagree, Julian.  I think SAs are easier to deal with when they're
> > batched.  True, I can't fix the first one in less than 3 minutes.  But
> > then I probably wouldn't even notice it that fast.  Batching them all
> > together means fewer updates and reboots.
>
> Batching also means some of these vulnerabilities could have been
> fixed earlier & less of a surge of demand on recipient admins time.
>
> An admin can find time to ameliorate 1 bug, not 8 suddenly together.
> Avoidance is called planning ahead. Giving warning of a workload.
> Like an admin plans ahead & announces an outage schedule for planned
> upgrade.
>
> Suddenly dumping 8 on admins causes overload on admin manpower.
> 8 reason for users to approach admin in parallel & say
> "FreeBSD seems riddled, how long will all the sudden unplanned
>  outages take ?  Should we just dump it ?"
> Dont want negative PR & lack of management.
>
> Cheers,
> Julian
> --
> Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen
> Kent
>  http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
>  Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers
> died.
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Greg Veldman]

On Wed, May 15, 2019 at 07:15:04PM +0200, Julian H. Stacey wrote:
> You make some good points, but all depend on variant circustances.

I think there's validity to both points of view, and as you say
I think a lot of it depends on circumstance.  For example on my
personal systems, where I can patch/update/change/whatever on a
whim, I agree I'd rather know sooner.  But I also do this
professionally, and at work it's much more difficult to get
a maintenance window.  In that setting, where you can't patch
and reboot a box every day, batching makes sense.  It allows
several defects to be fixed at once and actually reduces the
time you're sitting with publically known issues on your running
systems, waiting for RFC approval.

That said, there are perhaps some things that can be done to
make the process more predictable, which I'd submit for
consideration to the various groups on this thread.  First,
perhaps there could be some advance notice when a large batch
of fixes like this is about to drop.  Nothing that gives details,
but just something to allow enterprise admins to plan ahead and
possibly be ready when the details are released.  By way of
example, I'm thinking of how the Samba project handled a security
release which also dropped this week. [1][2]

Second, to ensure things are being fixed in a reasonable manner
and not waiting excessively long for a batch to queue up, perhaps
secteam@ could share vulnerability timing metrics in (for example)
quarterly reports, to include such things as time from initial
report to released fix, time under embargo, etc.  Again, doesn't
have to be bug-specific, but an average would be useful.  That
would set the stage for a meaningful debate based on actual data,
instead of just personal preferences.

[1] https://lists.samba.org/archive/samba-announce/2019/000477.html
[2] https://lists.samba.org/archive/samba-announce/2019/000478.html

-- 
Greg Veldman
free...@gregv.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Gordon Tetlow]

Hi. Your friendly neighborhood Security Officer here. I published the 5
advisories and 3 errata yesterday.

On Wed, May 15, 2019 at 07:15:04PM +0200, Julian H. Stacey wrote:
> Thanks Will,
> You make some good points, but all depend on variant circustances.
> 
> I prefer to be informed ASAP, to make my own decisons with max info ASAP,
> Not delayed.  I want freebsd.org to Not Delay fix announcements into batches.

All but one of the fixes was already in the STABLE branches. So if you
wanted to track something that would get things as immediate as
possible, I would recommend looking at the STABLE branches, you just
won't get freebsd-update bits there.

Just to put a line in the sand here, I will always be batching
advisories when it works in my judgement. Granted, this batch was larger
than I wanted it to be; I ran out of time over the past couple of months
to get everything together (real life and all getting in the way).

There are two reasons I will batch:
1. Our users and the industry have a preference for batched updates.
2. There is a large upfront cost for getting the freebsd-update bits
   built. Meaning the time to do 1 advisory vs the time to do 8 makes it
   worthwhile to batch. No offense, but I value my time. I only have so
   much to devote to FreeBSD.

> As soon as exploits are in the wild, some will exploit,
> not announcing until binary updates are ready gives black hats more time.

Welcome to the push/pull of dealing with security. It is a risk based
decision, but I have the unenviable position of trying to make the best
risk based decision for the entire community. By definition, not
everyone will be happy with the decision.

> PS Here seems (*) an example of something in text config didnt even
> need to wait for src/ let alone bin. * Not sure, I'll try it later,
> got to dash off line.
> 
> https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/001878.html
> ] IV.  Workaround
> ] Use 'restrict noquery' in the ntpd configuration to limit addresses that
> ] can send mode 6 queries.

I would note this is already the default config.

Best regards,
Gordon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Julian H. Stacey]

Thanks Will,
You make some good points, but all depend on variant circustances.

I prefer to be informed ASAP, to make my own decisons with max info ASAP,
Not delayed.  I want freebsd.org to Not Delay fix announcements into batches.

If other admins want to delay being told told to do upgrades until
there's lots more to consider & upgrade, they can dummy the delay
their receive end, just filtering announcements into their own
special box they read once per period.

As soon as exploits are in the wild, some will exploit,
not announcing until binary updates are ready gives black hats more time.


>  Whatever other negative things you can say about them, I don't hear 
> enterprise admins begging that Microsoft/Oracle/whoever would dribble out 
> patches one at a time each week instead of combining them like they do; it 
> seems like it works just fine for everyone else.

MS make lots of money from the addicted cluless, despite MS loosers
frequently complain eg that PCs are locked up again in mid auto
update & owner can't shut down to catch a plane or train. MS servers
I avoid like the plague.

PS Here seems (*) an example of something in text config didnt even
need to wait for src/ let alone bin. * Not sure, I'll try it later,
got to dash off line.

https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/001878.html
] IV.  Workaround
] Use 'restrict noquery' in the ntpd configuration to limit addresses that
] can send mode 6 queries.

Cheers,
Julian
-- 
Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
 http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
 Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Matt Garber]

> On May 15, 2019, at 12:28 PM, Andrea Venturoli  wrote:
> 
> On 5/15/19 6:16 PM, Matt Garber wrote:
> 
>> Exactly. If batching 8 (or more) individual bugs/issues together into
>> one release is really causing admin/manpower overload and angst,then
>> maybe it’s time in your situation to use the binary updates (which
>> would only be a single `freebsd-update` and reboot, so there would
>> be no ‘sudden unplanned outages’) rather than tracking src and
>> remediating each individual bug at a time.
> 
> Maybe I'm dumb, but I still don't get what "src vs binary" has to do with "8 
> vs 1"...
> I ran a single "svn update; make buildworld; make kernel; make installworld; 
> reboot", not 8...
> 
> bye
>   av.

Agreed. But if, say, you were tracking specific svn revisions rather than just 
jumping to the latest, I *guess* it might involve 8 separate builds?

I certainly prefer one, batched downtime event to address across all affected 
systems, regardless of binary updates or src, and I imagine most other 
individuals/companies/organizations do, too.


--
Matt

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Julian H. Stacey]

Kurt Jaeger wrote:
> Hi!
> 
> > > > Alternative is to for announcers to do Less work: 
> > > > Send each announcement when ready.
> 
> > > The problem is not the announcement, the problem is providing
> > > the freebsd-update.
> 
> > > If announcements are send when ready, and the freebsd-update is
> > > not ready, therefore, the timeframes to attack systems with unpatched
> > > problems are much longer.
> 
> > True as far as that goes for binary users, but often source patches
> > are available faster, which begs the question: when to announce ?
> > When there's diffs ? When diffs are commited to src/ (used to be the norm 
> > *) ?
> > When there's some binary update ? 
> > Whne a whole bunch of 8 arrive in 3 minutes ? Gasp !
> 
> Now I understand why you bring this up.
> 
> I guess the majority of users are using the binary update path.

Hmm, a distinct possibility, that could be a problem delaying announcements.

> Maybe re@ can explain how the process is for these steps ?

I assumed re@ (periodicaly overworked team who presumably collapse
in appreciated exhaustion after valuable work rolling releases),
were [largely] different people?

Cheers,
Julian
-- 
Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
 http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
 Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Andrea Venturoli]

On 5/15/19 6:16 PM, Matt Garber wrote:


Exactly. If batching 8 (or more) individual bugs/issues together into
one release is really causing admin/manpower overload and angst,then
maybe it’s time in your situation to use the binary updates (which
would only be a single `freebsd-update` and reboot, so there would
be no ‘sudden unplanned outages’) rather than tracking src and
remediating each individual bug at a time.


Maybe I'm dumb, but I still don't get what "src vs binary" has to do 
with "8 vs 1"...
I ran a single "svn update; make buildworld; make kernel; make 
installworld; reboot", not 8...


 bye
av.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Matt Garber]

> On May 15, 2019, at 12:12 PM, Will Andrews  wrote:
> 
> On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey  wrote:
> 
>> Batching also means some of these vulnerabilities could have been
>> fixed earlier & less of a surge of demand on recipient admins time.
>> 
>> An admin can find time to ameliorate 1 bug, not 8 suddenly together.
>> Avoidance is called planning ahead. Giving warning of a workload.
>> Like an admin plans ahead & announces an outage schedule for planned
>> upgrade.
>> 
>> Suddenly dumping 8 on admins causes overload on admin manpower.
>> 8 reason for users to approach admin in parallel & say
>> "FreeBSD seems riddled, how long will all the sudden unplanned
>> outages take ?  Should we just dump it ?"
>> Dont want negative PR & lack of management.
>> 
> 
> What admins prefer 8 downtime events instead of 1?
> 
> —Will.

Exactly. If batching 8 (or more) individual bugs/issues together into one 
release is really causing admin/manpower overload and angst, then maybe it’s 
time in your situation to use the binary updates (which would only be a single 
`freebsd-update` and reboot, so there would be no ‘sudden unplanned outages’) 
rather than tracking src and remediating each individual bug at a time. I 
understand that might be mutually exclusive with other reasons why you don’t 
already use binary updates or prefer to track src for the base system, but 
there are always compromises and trade-offs to everything, and batching seems 
preferable to any alternatives.

You’d seriously want to run reboots across a server fleet every other day for 
two weeks if there were 8 separate patches staggered out? That’s insanity, and 
is way more of a PR problem from a ‘should we just dump it’ perspective. You 
mention ‘announces an outage schedule for planned upgrade’, but that’s really 
its own form of internal batching – it shouldn’t make any difference if you’re 
technically pushing 1 or 8 bug/security fixes during that pre-identified period 
of time: all of your other internal processes like maintaining a test group for 
detecting regressions, using boot environments (or other storage features) to 
allow for rollbacks, etc. all continue to work as intended.

Any potential negative PR within your company/organization seems like it would 
be related to how else you’re handling the upgrade process(es), not whether the 
fixes are batched or not. Whatever other negative things you can say about 
them, I don’t hear enterprise admins begging that Microsoft/Oracle/whoever 
would dribble out patches one at a time each week instead of combining them 
like they do; it seems like it works just fine for everyone else.


¯\_(ツ)_/¯


Thanks,
—
Matt Garber


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Will Andrews]

On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey  wrote:

> Batching also means some of these vulnerabilities could have been
> fixed earlier & less of a surge of demand on recipient admins time.
>
> An admin can find time to ameliorate 1 bug, not 8 suddenly together.
> Avoidance is called planning ahead. Giving warning of a workload.
> Like an admin plans ahead & announces an outage schedule for planned
> upgrade.
>
> Suddenly dumping 8 on admins causes overload on admin manpower.
> 8 reason for users to approach admin in parallel & say
> "FreeBSD seems riddled, how long will all the sudden unplanned
>  outages take ?  Should we just dump it ?"
> Dont want negative PR & lack of management.
>

What admins prefer 8 downtime events instead of 1?

--Will.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Glen Barber]

On Wed, May 15, 2019 at 05:58:38PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > > Alternative is to for announcers to do Less work: 
> > > > Send each announcement when ready.
> 
> > > The problem is not the announcement, the problem is providing
> > > the freebsd-update.
> 
> > > If announcements are send when ready, and the freebsd-update is
> > > not ready, therefore, the timeframes to attack systems with unpatched
> > > problems are much longer.
> 
> > True as far as that goes for binary users, but often source patches
> > are available faster, which begs the question: when to announce ?
> > When there's diffs ? When diffs are commited to src/ (used to be the norm 
> > *) ?
> > When there's some binary update ? 
> > Whne a whole bunch of 8 arrive in 3 minutes ? Gasp !
> 
> Now I understand why you bring this up.
> 
> I guess the majority of users are using the binary update path.
> 
> Maybe re@ can explain how the process is for these steps ?
> 

This is an so@ thing (CCd).  re@ does not have any involvement in this
process.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Kurt Jaeger]

Hi!

> > > Alternative is to for announcers to do Less work: 
> > > Send each announcement when ready.

> > The problem is not the announcement, the problem is providing
> > the freebsd-update.

> > If announcements are send when ready, and the freebsd-update is
> > not ready, therefore, the timeframes to attack systems with unpatched
> > problems are much longer.

> True as far as that goes for binary users, but often source patches
> are available faster, which begs the question: when to announce ?
> When there's diffs ? When diffs are commited to src/ (used to be the norm *) ?
> When there's some binary update ? 
> Whne a whole bunch of 8 arrive in 3 minutes ? Gasp !

Now I understand why you bring this up.

I guess the majority of users are using the binary update path.

Maybe re@ can explain how the process is for these steps ?

-- 
p...@freebsd.org +49 171 3101372  One year to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Julian H. Stacey]

Hi, Reference:
> From: Kurt Jaeger 
> Date: Wed, 15 May 2019 17:38:36 +0200

Kurt Jaeger wrote:
> Hi!
> 
> > > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."
> > > > 
> > > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html
> > > > 
> > > > Volunteers who contribute actual fixes are very much appreciated;
> > > > But those styled as 'management' who delay announcements to batch floods
> > > > damage us.
> > > 
> > > 8 announcements and one freebsd-update is easier on the
> > > admin and the re-team than 8 announcements and 8 freebsd-update runs.
> > > 
> > > That's probably why they are batched. Because all of the fixes
> > > are bundled in one update.
> > > 
> > > If the re-team-capacity is limited, what would be the alternative?
> 
> > Alternative is to for announcers to do Less work: 
> > Send each announcement when ready.
> 
> The problem is not the announcement, the problem is providing
> the freebsd-update.
> 
> If announcements are send when ready, and the freebsd-update is
> not ready, therefore, the timeframes to attack systems with unpatched
> problems are much longer.

True as far as that goes for binary users, but often source patches
are available faster, which begs the question: when to announce ?
When there's diffs ? When diffs are commited to src/ (used to be the norm *) ?
When there's some binary update ? 
Whne a whole bunch of 8 arrive in 3 minutes ? Gasp !

* I happen to use src/ never use freebsd-update.
Equally bound to be some who use binary updates & not source

Cheers,
Julian
-- 
Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
 http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
 Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Julian H. Stacey]

Hi, Reference:
> From: Alan Somers 
> Date: Wed, 15 May 2019 08:32:26 -0600

Alan Somers wrote:
> On Wed, May 15, 2019 at 8:26 AM Julian H. Stacey  wrote:
> >
> > Hi core@,
> > cc hackers@ & stable@
> >
> > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."
> >
> > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html
> >
> > Volunteers who contribute actual fixes are very much appreciated;
> > But those styled as 'management' who delay announcements to batch floods
> > damage us. As they've previously refused to stop, it's time to sack them.
> >
> > Just send each announcement out when ready, no delays to batch them.
> > No sys admins can deal with 8 in 3 mins:
> >   Especially on multiple systems & releases.  Recipients start
> >   mitigating, then more flood in, & need review which are
> >   most urgent to interrupt to;  While also avoiding sudden upgrades
> >   to many servers & releases, to minimise disturbing server users,
> >   bosses & customers.
> >
> > Cheers,
> > Julian
> > --
> > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen 
> > Kent
> >  http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
> >  Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
> 
> I disagree, Julian.  I think SAs are easier to deal with when they're
> batched.  True, I can't fix the first one in less than 3 minutes.  But
> then I probably wouldn't even notice it that fast.  Batching them all
> together means fewer updates and reboots.

Batching also means some of these vulnerabilities could have been 
fixed earlier & less of a surge of demand on recipient admins time.

An admin can find time to ameliorate 1 bug, not 8 suddenly together.
Avoidance is called planning ahead. Giving warning of a workload.
Like an admin plans ahead & announces an outage schedule for planned upgrade.

Suddenly dumping 8 on admins causes overload on admin manpower.
8 reason for users to approach admin in parallel & say
"FreeBSD seems riddled, how long will all the sudden unplanned
 outages take ?  Should we just dump it ?"
Dont want negative PR & lack of management.

Cheers,
Julian
-- 
Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
 http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
 Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Kurt Jaeger]

Hi!

> > > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."
> > > 
> > > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html
> > > 
> > > Volunteers who contribute actual fixes are very much appreciated;
> > > But those styled as 'management' who delay announcements to batch floods
> > > damage us.
> > 
> > 8 announcements and one freebsd-update is easier on the
> > admin and the re-team than 8 announcements and 8 freebsd-update runs.
> > 
> > That's probably why they are batched. Because all of the fixes
> > are bundled in one update.
> > 
> > If the re-team-capacity is limited, what would be the alternative?

> Alternative is to for announcers to do Less work: 
> Send each announcement when ready.

The problem is not the announcement, the problem is providing
the freebsd-update.

If announcements are send when ready, and the freebsd-update is
not ready, therefore, the timeframes to attack systems with unpatched
problems are much longer.

-- 
p...@freebsd.org +49 171 3101372  One year to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Julian H. Stacey]

Kurt Jaeger wrote:
> Hi!
> 
> > PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."
> > 
> > https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html
> > 
> > Volunteers who contribute actual fixes are very much appreciated;
> > But those styled as 'management' who delay announcements to batch floods
> > damage us.
> 
> 8 announcements and one freebsd-update is easier on the
> admin and the re-team than 8 announcements and 8 freebsd-update runs.
> 
> That's probably why they are batched. Because all of the fixes
> are bundled in one update.
> 
> If the re-team-capacity is limited, what would be the alternative?

Alternative is to for announcers to do Less work: 
Send each announcement when ready.
Do not do extra work delaying, storing, batch announcing.
Announcements to recipients not delayed, without flooding.

> 
> -- 
> p...@opsec.eu+49 171 3101372One year to go !
> 

Cheers,
Julian
-- 
Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
 http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
 Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Kurt Jaeger]

Hi!

> PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."
> 
> https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html
> 
> Volunteers who contribute actual fixes are very much appreciated;
> But those styled as 'management' who delay announcements to batch floods
> damage us.

8 announcements and one freebsd-update is easier on the
admin and the re-team than 8 announcements and 8 freebsd-update runs.

That's probably why they are batched. Because all of the fixes
are bundled in one update.

If the re-team-capacity is limited, what would be the alternative?

-- 
p...@opsec.eu+49 171 3101372One year to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD flood of 8 breakage announcements in 3 mins.

[Alan Somers]

On Wed, May 15, 2019 at 8:26 AM Julian H. Stacey  wrote:
>
> Hi core@,
> cc hackers@ & stable@
>
> PR headline : "FreeBSD flood of 8 breakage announcements in 3 mins."
>
> https://lists.freebsd.org/pipermail/freebsd-announce/2019-May/date.html
>
> Volunteers who contribute actual fixes are very much appreciated;
> But those styled as 'management' who delay announcements to batch floods
> damage us. As they've previously refused to stop, it's time to sack them.
>
> Just send each announcement out when ready, no delays to batch them.
> No sys admins can deal with 8 in 3 mins:
>   Especially on multiple systems & releases.  Recipients start
>   mitigating, then more flood in, & need review which are
>   most urgent to interrupt to;  While also avoiding sudden upgrades
>   to many servers & releases, to minimise disturbing server users,
>   bosses & customers.
>
> Cheers,
> Julian
> --
> Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
>  http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
>  Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.

I disagree, Julian.  I think SAs are easier to deal with when they're
batched.  True, I can't fix the first one in less than 3 minutes.  But
then I probably wouldn't even notice it that fast.  Batching them all
together means fewer updates and reboots.

-Alan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"