On 12/20/2014 11:25 AM, Harlan Stenn wrote:
Michael Meier writes:
On 12/20/2014 08:13 AM, Harlan Stenn wrote:
Please tell me a valid use case for sticking with the older version.
"Because my auditor says so" is a valid but not good reason.
We barely have adequate resources to work on the mainline codebase. Did
you notice it's been 5 YEARS since the last stable release?
That is pretty much exactly the problem.
What would it take for your auditors to decide 4.2.8 is OK for use?
I think you misunderstood me there. I do not have any auditors to make
happy. "that is the problem" was referencing the "5 years since the last
stable release".
You just declared the development-version stable, that has a bazillion
changes from the last 5 years besides the actual security fixes.
We have over a TRILLION hours of operational experience with ntp4 in
this year alone. If even 90% of that is with older versions, that's
still 100 BILLION hours of operation with ntp-dev. If it's 99% with
older versions, that's still 10 BILLION hours of operation with ntp-dev.
Still not convinced? OK, what if it's 99.9% on the older code? 99.99%?
This is why I was comforable with releasing 4.2.8.
As best as I can tell, there are *no* cases where ntp-4.2.6 is better
than ntp-4.2.7 or ntp-4.2.8.
That may well be the case. Please note that I'm not opposing the release
of 4.2.8 as such, it is something that has been long overdue. But a new
major release is not suitable for a security-fix.
The point is that everybody trying to run stable services will still be
on 4.2.6 because until 2 days ago that simply was the version that was
declared the STABLE one. And even for those that do just run the stock
version without patching it, switching from 4.2.6 to .8 will probably
mean adapting their configfiles.
All major distributions (except maybe desktop-oriented ones) still ship
4.2.6. Distributions will not be happy to jump to a completely different
version outside of their release cycle, as at the very least they will
have to recheck their patches and default-configs. While it is fair to
argue that Redhat or SuSE have paid staff that can either do that or
backport the patches (if they get the necessary information), there are
other (community-run) distributions out there like e.g. Debian, where
this will significantly slow down distribution of a fixed version.
Leaving many vulnerable hosts on the general internet. That is never a
desirable situation, and in this case it might be the final nail in the
coffin of NTP. The big reflection-attacks using monlist were less than a
year ago, leaving "NTP = trouble" in peoples minds, and yet again there
will be sh*tloads of exploitable servers through NTP. Lots of providers
will probably just firewall away port 123. permanently this time.
I will have to rework our local patches (for our refclocks), and I most
certainly will have to rework all config files until they work again as
before. Both of which are things I do not like to do at extremely short
notice, much less so during my christmas vacation.
Have you sent those patches in?
Of course not, as noone except us will require them because noone else
has this exact type/version of refclocks. My point here is: You cannot
just assume everybody will be able to switch from 4.2.6 to .8 without
major effort.
Not releasing a 4.2.6p6 that has just the security-fixes really is a
giant "FUCK YOU" into the faces of your users.
Not how it was intended. Please take a deeper look at the situation.
NTF has no money to pay developers, only two developers are getting any
support for NTP development, and they are funded part-time.
That is far more paid developers than most open source projects have.
Certainly it should be possible for two part-time people to backport
some patches that fix buffer overflows?
We've known autokey was "past its prime" for a while now, and sadly
somebody recently found a way to exploit this. There is a replacement
for autokey in the wings, but I'll be surprised if that code is ready
for release before this summer.
So autokey is disabled in 4.2.8? What makes it so hard to disable it in
a 4.2.6p6 too?
Right now it doesn't even compile for me on SLES11,
because it seems to blindly depend on libbsd, which is simply not
available on SLES11. configure does not check for its availability and
just makes the compile fail due to an "undefined reference to
`arc4random_buf'".
A *lot* of testing has gone in to the code in general. There were two
security patches that did not get as much testing as I would have liked,
and these two have been the heart of these problems.
Nobody has ever opened a bug report about SLES11 and 4.2.7.
Well that's the thing: The people running enterprise distributions like
SLES or RHEL seldom try out "unstable" software like 4.2.7. You would
probably have gotten a bugreport some time after the release of 4.2.8.
Regardless, add -levent to the link list. That's where we'll find
arc4random_buf() if RAND_bytes() and RAND_pool() (from OpenSSL) are not
available.
Are you sure about -levent? If so, adding -levent does not work on
SLES11 - it does not contain arc4random_buf(). Possibly because SLES11
is shipping with the rather old libevent-version 1.4.5 and SSL-Support
was apparently a new feature in 2.0.x.
--
Michael Meier, HPC Services
Friedrich-Alexander-Universitaet Erlangen-Nuernberg
Regionales Rechenzentrum Erlangen
Martensstrasse 1, 91058 Erlangen, Germany
Tel.: +49 9131 85-28973, Fax: +49 9131 302941
[email protected]
www.hpc.rrze.fau.de
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
