8:33 a.m.
I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.
The main problem is that they don't fix all known security issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration. This was one of
the reasons why we dropped it from RHEL.
I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.
In Fedora, there seems to be only one package that has a dependency on
ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
problematic mode-6 protocol. It should work with ntpsec.
Thoughts?
--
Miroslav Lichvar
8:36 a.m.
On Mon, Nov 2, 2020 at 9:33 AM Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.
The main problem is that they don't fix all known security issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration. This was one of
the reasons why we dropped it from RHEL.
I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.
In Fedora, there seems to be only one package that has a dependency on
ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
problematic mode-6 protocol. It should work with ntpsec.
Thoughts?
That sounds fine to me. The only thing I really get concerned about is
whether we have the "ntpdate" tool, which comes from the ntp package.
As far as I know, ntpsec also includes it, so we should be fine.
--
真実はいつも一つ！/ Always, there's only one truth!
9:14 a.m.
On 11/2/20 9:33 AM, Miroslav Lichvar wrote:
I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.
The main problem is that they don't fix all known security issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration. This was one of
the reasons why we dropped it from RHEL.
I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.
In Fedora, there seems to be only one package that has a dependency on
ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
problematic mode-6 protocol. It should work with ntpsec.
Thoughts?
I use ntp heavily for multiple stratum 1 timeservers here. If you drop ntp, I will have
to build my own from source. Not a big problem, but I'd personally like to see ntp
stay available in Fedora.
Steve
9:23 a.m.
On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:
On 11/2/20 9:33 AM, Miroslav Lichvar wrote:
> I'm not sure how many users of ntp are there. As a replacement, we
> could package ntpsec. It is an actively maintained fork of ntp which
> has removed a lot of code and fixed or avoided most of the issues in
> ntp. What I don't like much about it is that they kept the mode-6
> protocol of NTP, which allows traffic amplification and is still
> causing problems on Internet, but I think the code and the project are
> definitely in a better shape than ntp. I can help with the packaging
> or review, and as a comaintainer if there is a volunteer for the
> role of the primary maintainer.
>
I use ntp heavily for multiple stratum 1 timeservers here. If you
drop ntp, I will have to build my own from source. Not a big problem,
but I'd personally like to see ntp stay available in Fedora.
Would NTPSec (https://www.ntpsec.org/accomplishments.html) work for you?
--
Tomasz Torcz 72->| 80->|
tomek(a)pipebreaker.pl 72->| 80->|
9:30 a.m.
On 11/2/20 10:23 AM, Tomasz Torcz wrote:
On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:
> On 11/2/20 9:33 AM, Miroslav Lichvar wrote:
>> I'm not sure how many users of ntp are there. As a replacement, we
>> could package ntpsec. It is an actively maintained fork of ntp which
>> has removed a lot of code and fixed or avoided most of the issues in
>> ntp. What I don't like much about it is that they kept the mode-6
>> protocol of NTP, which allows traffic amplification and is still
>> causing problems on Internet, but I think the code and the project are
>> definitely in a better shape than ntp. I can help with the packaging
>> or review, and as a comaintainer if there is a volunteer for the
>> role of the primary maintainer.
>>
>
> I use ntp heavily for multiple stratum 1 timeservers here. If you
> drop ntp, I will have to build my own from source. Not a big problem,
> but I'd personally like to see ntp stay available in Fedora.
Would NTPSec (https://www.ntpsec.org/accomplishments.html) work for you?
Probably. They appear to have kept the nmea and pps drivers. I'll have to build a
copy and give it a try to be sure.
Steve
9:37 a.m.
On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:
I use ntp heavily for multiple stratum 1 timeservers here. If you
drop ntp, I will have to build my own from source. Not a big problem, but I'd
personally like to see ntp stay available in Fedora.
I have few stratum-1 servers too, but I'm not running ntp.
What reference clock do you have? Unless it's something very rare, you
shouldn't need ntp for that. GPS receivers are well supported by gpsd
and ntpsec kept most of the ntpd drivers for hardware that is still
widely used.
There is also the ntp-refclock package which contains all ntpd drivers
with a thin wrapper that allows them to be used with chrony, ntpsec,
or basically any NTP server.
--
Miroslav Lichvar
10:14 a.m.
On 11/2/20 10:37 AM, Miroslav Lichvar wrote:
On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:
> I use ntp heavily for multiple stratum 1 timeservers here. If you drop ntp, I will
have to build my own from source. Not a big problem, but I'd personally like to see
ntp stay available in Fedora.
I have few stratum-1 servers too, but I'm not running ntp.
What reference clock do you have? Unless it's something very rare, you
shouldn't need ntp for that. GPS receivers are well supported by gpsd
and ntpsec kept most of the ntpd drivers for hardware that is still
widely used.
I played around for a while with gpsd and never could get it to behave properly. My ref
clocks are NMEA, and I thought gpsd would be easy, but sometimes it wouldn't recognize
the PPS, other times it was off by 1 second or showed milliseconds of error. So in the
end I went back to plain ntp.
I'll try ntpsec.
Steve
11:09 a.m.
Miroslav Lichvar wrote:
The main problem is that they don't fix all known security
issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration.
That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.
I'm not sure how many users of ntp are there. As a replacement,
we
could package ntpsec.
Judging only from their own website, it seems that switching to NTPsec
would be a great improvement.
I'll have to investigate whether I can migrate all my usecases to
Chrony.
Björn Persson
11:22 a.m.
On Mon, Nov 2, 2020 at 12:10 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
Miroslav Lichvar wrote:
> The main problem is that they don't fix all known security issues. In
> the CVE list I see about 10 issues that were not fixed at all or only
> partially, some exploitable in default configuration.
That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.
> I'm not sure how many users of ntp are there. As a replacement, we
> could package ntpsec.
Judging only from their own website, it seems that switching to NTPsec
would be a great improvement.
I'll have to investigate whether I can migrate all my usecases to
Chrony.
Work migrated to Chrony a year or so ago. The only thing I use from
ntp is the "ntpdate" tool. Everything else is chrony now. :)
--
真実はいつも一つ！/ Always, there's only one truth!
11:37 a.m.
On 11/2/20 9:22 AM, Neal Gompa wrote:
Work migrated to Chrony a year or so ago. The only thing I use from
ntp is the "ntpdate" tool. Everything else is chrony now. :)
out of curiosity, what's lacking for your use case?
ntpdate, here, was primarily for "set it now" interventions.
that, at least, is easily done with
chronyd -q 'server <time server> iburst'
11:37 a.m.
On Mon, Nov 2, 2020 at 12:37 PM PGNet Dev <pgnet.dev(a)gmail.com> wrote:
On 11/2/20 9:22 AM, Neal Gompa wrote:
> Work migrated to Chrony a year or so ago. The only thing I use from
> ntp is the "ntpdate" tool. Everything else is chrony now. :)
out of curiosity, what's lacking for your use case?
ntpdate, here, was primarily for "set it now" interventions.
that, at least, is easily done with
chronyd -q 'server <time server> iburst'
Mostly third-party scripts and programs that have it hardcoded.
Otherwise I wouldn't use it at all.
--
真実はいつも一つ！/ Always, there's only one truth!
11:41 a.m.
On Mon, Nov 02, 2020 at 06:09:18PM +0100, Björn Persson wrote:
Miroslav Lichvar wrote:
> The main problem is that they don't fix all known security issues. In
> the CVE list I see about 10 issues that were not fixed at all or only
> partially, some exploitable in default configuration.
That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.
There is no official list. You would need to inspect the code to see
what have been actually fixed. For some CVEs they only provided
mitigations and in some cases the fixes were wrong or incomplete.
You can look for my comments in the upstream bugzilla.
The list of 10 issues that I think are not (fully) fixed yet follows.
Probably not complete or completely accurate, but if you need details
about a specific issue, I can check the code.
CVE-2013-5211
CVE-2015-7705
CVE-2015-7974
CVE-2015-7979
CVE-2015-8139
CVE-2016-1548
CVE-2016-4955
CVE-2016-7426
CVE-2018-7170
CVE-2020-13817
--
Miroslav Lichvar
3:32 p.m.
I don't have objections to retiring the ntp tool, as long as there's something to
take its place, and as long as a command argument compatible ntpdate tool still exists. I
tend to use ntpdate much more often than I enable the ntp service. Right now ntpdate runs
on boot on my PinePhone's Fedora 33 install.
3:35 p.m.
On Mon, Nov 2, 2020 at 9:33 AM Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.
So, use "chrony" instead? Is the functionality sufficient, and can
the ntp.conf files be ported gracefully to a compatible chrony.conf
setting?
3:52 p.m.
On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
So, use "chrony" instead?
For some use cases, there is also the option of
systemd-timesyncd as a ntp client.
Is the functionality sufficient
As always, given the different use cases, the answer
is maybe.
Here is a quick comparison: https://chrony.tuxfamily.org/comparison.html
and can the ntp.conf files be ported gracefully to a
compatible chrony.conf setting?
Again, it would depend on how you are using ntpd.
For the cases where the system is just a client of
the protocol trying keep the right time, it should be
easy to migrate to either chrony (or systemd-timesyncd).
If you are using hardware to discipline your server
using one/more of the hardware specific drivers
things get more complicated.
11:58 p.m.
Question : I know that FreeIPA at one point did not work well with
chrony and required the installation of ntp. This might cause an
issue.
On Mon, Nov 2, 2020 at 3:54 PM Gary Buhrmaster
<gary.buhrmaster(a)gmail.com> wrote:
>
> On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>
> > So, use "chrony" instead?
>
> For some use cases, there is also the option of
> systemd-timesyncd as a ntp client.
>
> > Is the functionality sufficient
>
> As always, given the different use cases, the answer
> is maybe.
>
> Here is a quick comparison: https://chrony.tuxfamily.org/comparison.html
>
> > and can the ntp.conf files be ported gracefully to a
> > compatible chrony.conf setting?
>
> Again, it would depend on how you are using ntpd.
> For the cases where the system is just a client of
> the protocol trying keep the right time, it should be
> easy to migrate to either chrony (or systemd-timesyncd).
> If you are using hardware to discipline your server
> using one/more of the hardware specific drivers
> things get more complicated.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2:11 a.m.
On Mon, Nov 02, 2020 at 11:58:53PM -0600, Alex Thomas wrote:
Question : I know that FreeIPA at one point did not work well with
chrony and required the installation of ntp. This might cause an
issue.
That's not a problem anymore. Support for chrony was added in 4.7.0,
released in 2018, so we are good.
https://www.freeipa.org/page/Releases/4.7.0#Time_server_change_to_chronyd
--
Tomasz Torcz 72->| 80->|
tomek(a)pipebreaker.pl 72->| 80->|
3:31 a.m.
On Mon, Nov 02, 2020 at 09:52:59PM +0000, Gary Buhrmaster wrote:
On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia
<nkadel(a)gmail.com> wrote:
> So, use "chrony" instead?
For some use cases, there is also the option of
systemd-timesyncd as a ntp client.
timesyncd is a very minimal NTP client. It can be recommended in some
specific use cases, like a local network with a trusted server, but
not in the most common case of a client using random public servers on
Internet. There are other minimal clients that should be considered
before timesyncd, e.g. openntpd or the busybox ntpd.
> and can the ntp.conf files be ported gracefully to a
> compatible chrony.conf setting?
In the vast majority of cases, yes, it can. There is even a ntp2chrony
script for automatic conversion.
The most common thing that people seem to miss is the mode-6 protocol,
which is needed by some monitoring tools. That won't be supported in
chrony, but it is in ntpsec.
Autokey has been superseded by NTS.
Broadcast/multicast modes are better supported by PTP (linuxptp).
If you are using hardware to discipline your server
using one/more of the hardware specific drivers
things get more complicated.
Reference clocks shouldn't be a big issue. The refclock drivers from
ntp will stay in Fedora, at least for now, in the ntp-refclock
package. In future it might need to be switched to the ntpsec drivers.
For GPS receivers, which are by far the most common reference clocks,
there is also gpsd.
--
Miroslav Lichvar
1269
days inactive
1270
days old
17 comments
10 participants
participants (10)
-
Alex Thomas -
Björn Persson -
Gary Buhrmaster -
Miroslav Lichvar -
Neal Gompa -
Nico Kadel-Garcia -
PGNet Dev -
Steven A. Falco -
Subsentient -
Tomasz Torcz