NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Feel free to edit this page, adding questions, answers, and comments!

-- HarlanStenn - 06 Dec 2004

I've just gone through the MaintainerIssues page (which has recently been updated) again but this does not yet seem to solve the problem we have with bug #841.

Normally I'm used to understand what I am doing, and also why I am doing something. However, I still don't understand why a patch which has been written for stable has to be able to be pulled into dev in order to be accepted.

The nature of the -dev repository is that large parts of the -dev code differ from the -stable code, otherwise the -dev repo would be obsolete. If the same bug is both in -stable and in -dev then of course the approach described in MaintainerIssues is the best way to handle this. In this case there's a good chance that the affected code is still similar in -stable and -dev, so a patch for -stable should basically also pull into -dev cleanly.

However, that requirement makes absolutely no sense at all if a fix is only for -stable because the associated code in -dev differs from -stable and does not have the bug which shall be fixed.

In the particular case of bug #841 the change for -dev has been made by Frank back in May 2007. I have backported this for -stable in April 2008. So if you try to pull the patch for -stable into -dev this is the same as if you try to pull the same patch in twice, which makes absolutely no sense.

-- MartinBurnicki - 04 Aug 2008

Martin,

The heart of the matter is pretty much because of the workflow "direction", that -dev be a superset of -stable.

In general, we want to be able to apply bugfixes to -stable and have those fixes be a part of -dev. The development done in -dev must not appear in -stable (until it is time for the next major/minor release).

If anybody commits a patch to -stable that cannot be cleanly pulled in to -dev, it makes any future work that wants to follow the "normal" workflow impossible, because that future work cannot be pulled from -stable to -dev.

If we knew that we were issuing the last patch to -stable and there would be no further patches before the next release then it is arguable that we could break this rule. However emergencies happen, and I consider NTP to be "critical" network infrastructure code. I do not want to take the chance that we would decide to break this rule and then have a situation where it was critical that we make a patch to -stable and -dev.

Another way to look at this is that I have a strong preference for keeping things simple and working, and not making exceptions to the rules.

Therefore, even though the bug was first fixed in -dev, by backporting the patch to -stable I believe it is still important that -stable pull cleanly into -dev specifically because if we cannot, it makes it very difficult for me to do any future work on -stable.

-- HarlanStenn - 04 Aug 2008