r34 - 2018-08-24 - 06:08:39 - HarlanStennYou are here: NTP >

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.8p14 was released on 03 March 2020. It addresses 2 medium-severity security issues in ntpd, and provides 47 non-security bugfixes and 4 other improvements 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.

Release Steps

Here are notes on what to do to create a release.

Stable beta releases
Stable Point RC
Stable Point Release
Stable Major Release
Dev Releases
Dev RC Releases
Spool area nitty-gritty
- .ignoreme* files

Should this information continue to be here, or should we move it to the Committers web, or perhaps the Staff web, or a RelEng area?

Staff:NtpReleaseAnnouncements needs work.

NOTE: on deacon, builds currently require CC=gcc

NOTE FOR STABLE: if /backroom/snaps/BUMP contains 1, /backroom/snaps/Makefile will bump the version number.

Stable beta releases

TBD

Stable Point RC

In the master /backroom/ntp-stable directory:

make distcheck just to be sure it works
Update packageinfo.sh (read the comments in the file) and checkin/commit
If "stable has new changes!" email has been sent, /backroom/snaps/.mksnap-$REPO-pull must be removed.
touch /backroom/snaps/.stable-ok-to-roll

It's often easier to let the 'snap' process handle the autogen stuff...

Stable Point Release

Handle the NewsFileMaintenance and have somebody to review those changes. Check-in/commit the file.
The ChangeLogMaintenance is no longer needed, as we do that as part of the normal checkin process now.
in packageinfo.sh set:
- rcpoint=GO
- If there will be no RC, then the only thing to do is bump the point value, which will be handled automatically by the scripts/build/UpdatePoint script.
- Run scripts/build/UpdatePoint -t stable to see how this should look.
check-in and commit NEWS, ChangeLog and packageinfo.sh
make to get the generated file timestamps sync'd (the change to packageinfo.sh triggers version number updates, which triggers autogen)
make distcheck just to be sure it works. On deacon that should be make distcheck NTP_DCF="--enable-local-libopts --enable-local-libevent --disable-problem-tests --with-net-snmp-config=/bin/false"
- The tarball will be named foo-RCGO - no, that used to be what it was called.
- Remember to bk unedit `cat .point-changed-filelist`
- bk status -v should be clean
- bk gfiles -c should be clean
touch /backroom/snaps/.stable-ok-to-roll

Stable Major Release

Also see the section below on Dev RC Releases.

These are kinda nasty.

It involves:

visit http://bugs.ntp.org/editversions.cgi and create the new version choice for bugzilla.
Handle the NewsFileMaintenance and have somebody to review those changes. Check-in/commit the file into -dev.
pulling from -dev to -stable
Probably doing ChangeLogMaintenance, making sure the top of the ChangeLog file is the --- marker.
wiggling versions in packageinfo.sh in both -stable and -dev, and committing these changes.
- for -stable:
  - repotype=stable
  - ++minor
  - prerelease=
  - point=NEW
  - rcpoint=
  - commit packageinfo.sh
- for -dev:
  - bump minor by 2
  - prerelease=
  - point=NEW
  - rcpoint=GRONK
  - commit packageinfo.sh
pulling -stable into -dev, using the -dev version of the packageinfo.sh file.
After the -stable roll, pull into -dev again, keeping the -dev versions of all of the AutoGen files. Talk to Dave Hart about this!
Go in to the snap directory and clean out the A.* files and the old tarballs, etc.

Dev Releases

These pretty much happen automatically - I don't have to do anything special for these.

There are "normal" and RC -dev releases.

Dev RC Releases

These are easy in and of themselves, but consider things like UpdatingLibopts if we are certain we won't be issuing any more -stable releases before the next major -stable release.

Spool area nitty-gritty

The public spool area contains, for example:

drwxrwxr-x   6 mills    ntp           21 Nov  6 23:26 .
drwxrwsr-x   9 ntp      ntp           12 Jun  5  2007 ..
-rw-r--r--   1 ntp      ntp            0 Jun 16  2007 .changes-dev
-rw-r--r--   1 ntp      ntp        10257 Jun 20  2007 .changes-stable
-rw-r--r--   1 ntp      ntp           76 Nov  6 22:32 .ignoreme-dev
-rw-r--r--   1 ntp      ntp           66 Sep 12 00:24 .ignoreme-stable
-rw-r--r--   1 ntp      ntp           74 Oct 29 04:41 .ignoreme-stable-rc
-rw-r--r--   1 ntp      ntp       103178 Nov  6 22:32 ChangeLog-dev
-rw-r--r--   1 ntp      ntp        60698 Oct  9  2009 ChangeLog-dev-rc
-rw-r--r--   1 ntp      ntp        77294 Oct 29 04:41 ChangeLog-stable
-rw-r--r--   1 ntp      ntp           45 Sep 11 16:29 ChangeLog-stable-rc
-rw-r--r--   2 ntp      ntp         6825 Sep 11 16:29 NEWS
-rw-r--r--   1 ntp      ntp          817 Apr 12  2006 README.versions
drwxrwxr-x   2 ntp      ntp           43 Dec 31  2004 ntp-4.0
drwxrwxr-x   2 ntp      ntp            6 Oct  8  2006 ntp-4.1
drwxrwxr-x   2 ntp      ntp          136 Oct 29 04:41 ntp-4.2
-rw-r--r--   2 ntp      ntp      4338873 Jul  8 22:39 ntp-4.2.6p2.tar.gz
-rw-r--r--   2 ntp      ntp           50 Jul  8 22:39 ntp-4.2.6p2.tar.gz.md5
-rw-r--r--   2 ntp      ntp      4361657 Oct 29 04:41 ntp-4.2.6p3-RC8.tar.gz
-rw-r--r--   2 ntp      ntp           50 Oct 29 04:41 ntp-4.2.6p3-RC8.tar.gz.md5
drwxrwxr-x   2 ntp      ntp          785 Nov  6 22:32 ntp-dev

The snapshot roll process updates the .ignoreme-* files and the ChangeLog* files. A script that runs on the UDel FTP server handles updating the links to the latest files.

It looks like the .changes* files are no longer needed - Steve, do you agree?

`.ignoreme*` files

stable updates .ignoreme-$NAME, while dev updates .ignoreme-$REPO. $REPO is either stable or dev (as appropriate). $NAME is $REPO for any (dev or stable) releases, and is $REPO-rc for any RC or beta (dev or stable) releases.