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.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Q/A page for the MaintainerIssues
Feel free to edit this page, adding questions, answers, and comments!
- 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.
- 04 Aug 2008
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.
- 04 Aug 2008