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.

ChangeLog Maintenance

ChangeLog in -dev

Just add new entries to the front of the list.

If a change is being applied to both -stable and -dev, only add the ChangeLog entry to -stable, as it will get pulled in to -dev from -stable.

ChangeLog in -stable

Add new entries to the front of the list, just after the initial --- and blank lines. In other words, the file should look like this:

 ---
 (empty line)
 (your new entries)
 * old entry 1
 * old entry 2
 (empty line)
 ---

When rolling a new release, the "release" line at the top:

   * (version) YYYY/MM/DD Released by Name <email>

is automatically prepended to the ChangeLog file by the snapshot process.

(The idea for the "date" was suggested independently by both SteveKostecke and, much later, MartinBurnicki.)

ChangeLog Format

The Release Announcement Generator currently supports the following ChangeLog entries:

  * [Bug NNN] a change which fixes a bug
  * [Sec NNN] a security-related bugfix
  * a change added by the development process

Multi-line ChangeLog entries are properly supported.

Other type of entieries which may be useful include:

  * [Dev NNN] a change which fixes a bug triggered by the development process
  * [Bug NNN - Backward Incompatible] a backward incompatible bugfix
  * [Backward Incompatible] a backward incompatible change added by
     the development process
  * [Deprecated] a change that removes something we have deprecated

I was chatting with Steve and noted that many of the bugs we fix in -dev were bugs that were introduced in -dev and there may be value in distinguishing these from bugs that were discovered in a -stable release.

There will be times when we think we have a [Dev NNN] bugfix and discover it is really a [Bug NNN] issue. When this happens we should watch what happens in the generated message script, as it would probably make a change to a pre-existing entry, which seems to mess up the script.

What about a deprecation that is backward-incompatible?

-- HarlanStenn - ?? ??? ????

Improving the ChangeLog format

When pulling from -stable to -dev how should we get the ChangeLogTag copied from "below the line" to the head of the list? And just because I think it's a good idea to get that information up top doesn't mean that others agree.

The first -dev roll after a major release of -stable does not need to duplicate the ChangeLogTag.

-- HarlanStenn - 17 Aug 2008

We've started to address this by adding lines like:

* Include (4.2.6p1-RC3) - [Bug 1450] Option to exclude warnings not
  unconditionally defined on Windows.

to the -dev ChangeLog file. These break Steve's current parser, and Steve suggests we use something like:

* [Bug 1450] from (4.2.6p1-RC3): Option to exclude warnings not
  unconditionally defined on Windows.

instead.

-- HarlanStenn - 2010-05-05