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.
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