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.
Time to add a third repository?
For several (many?) years we have been supporting 2 repositories for NTP:
ntp-stable containing stable/production releases
ntp-dev containing development work
We have also supported "snapshot tarballs" for each of these releases for quite some time. With the recent deployment of the new release numbering scheme
, we have also changed the software download links on the top-right-hand-side column of the site to advertise the latest 'point' releases of the code.
Given that any commits to
will result in the automatic production of a new 'point' release being published, I am thinking that it might be a good idea to have a 3rd published repository, namely:
ntp-stable-qa containing pending changes for
would be a "staging" repo, so proposed changes could be more widely tested before they are officially released in
Would this really buy us much if we don't have tarballs for it?
If we have tarballs for these releases, how should we identify them? If we can identfy these and keep them separate from "regular"
tarballs, we can do this with the existing 2 repos.
It will be pretty easy to release "real" and "interim"
tarballs; we can set the
to identify these releases. Where should these tarballs be dropped?
Steve suggests the following progression:
noting this would keep an unbroken series of patch levels and keep us with 2 repos.
The tricky bit is that on a "bump" that brings us to an RC, we'd need to bump the point and append -RC.
Future bumps would only bump the RC count.
When it went live, we'd strip the -RC and leave the point alone.
Comments/discussion are welcome (below here, please).
We have implemented Steve's suggestion, so at this point there seems to be no need to create a third repository.
- 22 Aug 2006