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
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
.
Otherwise, add new entries to the appropriate locations in the top-section of the list.
ChangeLog
in -stable
Add new entries to the appropriate location of the top part of the list, just after the initial
---
and blank line. In other words, the file should look like this:
---
(empty line)
* [Sec NNN] from smaller to larger numbers
* CID NNN from smaller to larger numbers - Coverity IDs
* [Bug NNN] from smaller to larger numbers
* oldest other entry
* ...
* newest other entry
(empty line) [optional]
---
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:
* [Sec NNN] a security-related bugfix
* [Bug NNN] a change which fixes a bug
* a change added by the development process
Multi-line ChangeLog entries are properly supported.
Other type of (currently unsupported) entries 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
Harlan's second choice looks cleaner to me because it keeps all [Bug NNN], and other tags, tags at the beginning of the line.
--
SteveKostecke - 2010-05-05
I'm now looking at:
* [Bug 1450] (from 4.2.6p1-RC3): Option to exclude warnings not
unconditionally defined on Windows.
or
* [Bug 1450] from 4.2.6p1-RC3: Option to exclude warnings not
unconditionally defined on Windows.
--
HarlanStenn - 2010-05-05