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? What are they doing to make that happen? > 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. > 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 thost patches in? > 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. 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. > To make matters worse, it doesn't even seem like too much testing has > gone into 4.2.8. 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. Or is this only a problem with the ntp-keygen (or some other security patch) in 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. I'm working on a patch for that now. > So unfortunately, that means that with the information that is currently > available and the fact that 4.2.8 is absolutely unusable even after just > spending two hours of my christmas vacation on it, I cannot take the risk. > I just took all four of our public stratum 1 NTP-servers offline. That is sad, and it might well be the best choice for you. I wanted to get 4.2.8 out the door within a year after releasing 4.2.6. It took 5 years, and while I would have loved to have had another month for testing, that's not how things worked out. If I had a full-time job I'd be able to put maybe 20-30 hours/week into network time. But I'd also not have to worry about paying my bills. I've been working (volunteering) over 105 hours/week on these things for over 3 years' time now. It's my choice to do what I've been doing. If NTF can get funding to pay folks to work on network time, that will be my full-time (paid) job, and a bunch of other folks will be able to do that as well. I think that will be a "win" for a lot of folks. Others may see no need for this. They might be right. And their way of thinking may come to pass. This situation is very similar to voting. And in this case, an "abstain" is a "no" vote. -- Harlan Stenn <[email protected]> http://networktimefoundation.org - be a member! _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
