Michael Meier writes: > 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".
OK. So what did you do to help make the release of 4.2.8 happen faster? > >> 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. It would have taken weeks longer to have put the security fixes into 4.2.6 and have them also work in ntp-dev. And even so, I was ready to release 4.2.8 now anyway - the security fixes just made the release more "important". The few build problems we have seen are all related to the security patches. Furthermore, 4.2.6 would be EOL'd when 4.2.8 came out anyway, so it's not clear to me yet how patching 4.2.6 for these problems would really accomplish anything more than delaying the release cycle by a few weeks' time. That last sentence was a polite way of saying "in other words, how would it not have been a waste of time and effort?" Remember, these same build problems would have likely happened with 4.2.6p6 as well. > 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. NTP is a community-run release too. I didn't want to significantly slow down the 4.2.8 release *and* delay the release of security patches. > 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. People will make their choices. NTP has an *enviable* security record. It's way better than ssh, ssl, apache, SQL, bind, sendmail, or many other protocols/packages. Look at how easy it has been to rootkit Linux (for example). Perhaps people should stop running all of these programs, too. > >> 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. OK, so your solution is to "kill the messenger"? And as for your local refclock changes, I would like to separately hear about them. I want to see if we can improve refclock support in a way that would not require recompiling C drivers. > >> 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? Most open source projects don't have anywhere near the deployment rates or operational hours we do, either. Or the portability we have, or the algorithmic and operational complexity. I looked at my work pile. If there were 4 or 5 copies of me I'd be able to keep up with my current known workload. That's just me, that's not anything else that needs to be done. That's somewhere north of 10 full-time developers. I think I have a pretty good idea of what needs to be done to keep the NTP project moving forward, and what items are the most critical. I understand and appreciate your belief that "gee, wouldn't it be better if you did X instead of Y", but you are not walking in my shoes and, frankly, you haven't really been all that involved in either the development or maintenance of NTP. You and I do not have the same "perspective" on the problem. Please note - I am *only* saying you and I have different perspectives on the problem. I firmly believe there is more stuff I should be aware of. > > 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? No, it's not disabled. The bad problems were fixed with these patches. There are other problems that still need to be fixed. But again, several of these recent security issues do not require autokey. We even documented how to disable autokey. But to say it one more time, several of the recent issues do not require autokey. > >> 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. There is, in general, nothing "unstable" about 4.2.7. I wrote that before, but you seem to have ignored it. There hasn't been anything unstable about 4.2.7 in a long time. What has been blocking 4.2.8 are some pesky bugs in relatively unused corners of the code. > > 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. Then build 4.2.8 with --enable-local-libevent . And if this only affects ntp-keygen, that's not a critical piece of your software deployment, is it? It's been a 17 hour day for me. Yesterday was an 18 hour day. Time for sleep. H _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
