From hmurray at megapathdsl.net Sun Aug 2 21:27:05 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Sun, 02 Aug 2020 14:27:05 -0700 Subject: Restrict own servers Message-ID: <20200802212705.127A2406061@ip-64-139-1-69.sjc.megapath.net> >From an ntp.comf: # Note that "restrict" applies to both servers and clients, so a configuration # that might be intended to block requests from certain clients could also end # up blocking replies from your own upstream servers. That's not totally correct for ntpsec. When setting up a server via DNS or pool it pokes a hole in any restrictions and logs a message. There are probably cases where that's not the right thing to do. It's necessary if you block most of the world. You can poke your own holes if you are using DNS but there isn't any sane way to do that when using the pool. Maybe there should be a way to say "no pool servers from xxx/16". We could do that with another restrict bit. -- These are my opinions. I hate spam. From gem at rellim.com Wed Aug 12 03:02:22 2020 From: gem at rellim.com (Gary E. Miller) Date: Tue, 11 Aug 2020 20:02:22 -0700 Subject: =?UTF-8?B?4pyYJ01PREVfQlJPQURDQVNUeCc=?= Message-ID: <20200811200222.4a4be424@rellim.com> Yo All! I just updated my NTPsec, and it is not working. # ntpmon Traceback (most recent call last): File "/usr/local/bin/ntpmon", line 343, in peer.associd) File "/usr/local/lib/python2.7/site-packages/ntp/util.py", line 1098, in summary elif hmode == ntp.magic.MODE_BROADCASTx: AttributeError: 'module' object has no attribute 'MODE_BROADCASTx' I look in the git directory for MODE_BROADCASTx, but I do not see it defined in Python: pi /usr/local/src/NTP/ntpsec # fgrep MODE_BROADCASTx * -r Binary file build/main/pylib/util.pyo matches build/main/pylib/util.py: elif hmode == ntp.magic.MODE_BROADCASTx: Binary file build/main/pylib/util.pyc matches include/ntp.h:#define MODE_BROADCASTx 5 /* broadcast mode */ pylib/util.py: elif hmode == ntp.magic.MODE_BROADCASTx: What am I missing? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From jamesb.fe80 at gmail.com Wed Aug 12 03:26:50 2020 From: jamesb.fe80 at gmail.com (James Browning) Date: Tue, 11 Aug 2020 20:26:50 -0700 Subject: =?UTF-8?B?UmU6IOKcmCdNT0RFX0JST0FEQ0FTVHgn?= In-Reply-To: <20200811200222.4a4be424@rellim.com> References: <20200811200222.4a4be424@rellim.com> Message-ID: On Tue, Aug 11, 2020, 8:02 PM Gary E. Miller via devel wrote: > Yo All! > > I just updated my NTPsec, and it is not working. > > # ntpmon > Traceback (most recent call last): > File "/usr/local/bin/ntpmon", line 343, in > peer.associd) > File "/usr/local/lib/python2.7/site-packages/ntp/util.py", line 1098, in > summary > elif hmode == ntp.magic.MODE_BROADCASTx: > AttributeError: 'module' object has no attribute 'MODE_BROADCASTx' > > I look in the git directory for MODE_BROADCASTx, but I do not see > it defined in Python: > > pi /usr/local/src/NTP/ntpsec # fgrep MODE_BROADCASTx * -r > Binary file build/main/pylib/util.pyo matches > build/main/pylib/util.py: elif hmode == ntp.magic.MODE_BROADCASTx: > Binary file build/main/pylib/util.pyc matches > include/ntp.h:#define MODE_BROADCASTx 5 /* broadcast mode */ > pylib/util.py: elif hmode == ntp.magic.MODE_BROADCASTx: > > What am I missing? > Ntp.magic and ntp.control are auto generated fro c headers by wscript. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmurray at megapathdsl.net Wed Aug 12 04:10:08 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 11 Aug 2020 21:10:08 -0700 Subject: 'MODE_BROADCASTx'Mime-Version: 1.0 Message-ID: <20200812041008.B3CA040605C@ip-64-139-1-69.sjc.megapath.net> There are a handful of modes that we don't support. I changed them from MODE_FOO to MODE_FOOx so any use would break at compile time and we would fix it. That was back in April. My best guess is that you have only half updated your system. You have a new ntpmon but it is using an old pylib/magic.py -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Wed Aug 12 04:21:37 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 11 Aug 2020 21:21:37 -0700 Subject: ntp in /etc/services Message-ID: <20200812042137.4216F40605C@ip-64-139-1-69.sjc.megapath.net> I'm scanning for 123, trying to make sure all the old references to 123 for the NTS port number get changed to 4460. docs/debug.adoc says: 1. Verify the +/etc/services+ file host machine has an entry for 123/udp. If you are using NTS, you must also have an entry for 123/tcp. Currently, the code doesn't need /etc/services Is that a bug, or should I remove that chunk of text? ---------- ntp.h has #define NTP_PORT 123 /* included for non-unix machines */ #define NTP_PORTA "123" /* or unix without /etc/services */ I think all the places that might look for "ntp" via /etc/services have been changed to use NTP_PORTA -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Wed Aug 12 09:44:27 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 12 Aug 2020 02:44:27 -0700 Subject: ntp in /etc/services In-Reply-To: Message from Hal Murray of "Tue, 11 Aug 2020 21:21:37 PDT." <20200812042137.4216F40605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20200812094427.452F040605C@ip-64-139-1-69.sjc.megapath.net> > Is that a bug, or should I remove that chunk of text? That doesn't seem very clear. Let me try again. The documentation mentions /etc/services The current code doesn't use it. It passes "123" rather than "ntp" to the DNS lookup routines. How should we fix that? 1) fix documentation (easy, remove 2 lines) 2) change code to use /etc/services The second choice might be interesting for some reason that I'm not aware of. There is another possibility -- a configure time option. That doesn't seem interesting to me but might be appropriate if using /etc/services is the right thing to do but some systems don't support it or we decide not to use /etc/services in the normal case but there is some obscure case that needs it. -- These are my opinions. I hate spam. From gem at rellim.com Wed Aug 12 17:45:31 2020 From: gem at rellim.com (Gary E. Miller) Date: Wed, 12 Aug 2020 10:45:31 -0700 Subject: 'MODE_BROADCASTx'Mime-Version: 1.0 In-Reply-To: <20200812041008.B3CA040605C@ip-64-139-1-69.sjc.megapath.net> References: <20200812041008.B3CA040605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20200812104531.00b6fda4@rellim.com> Yo Hal! On Tue, 11 Aug 2020 21:10:08 -0700 Hal Murray wrote: > There are a handful of modes that we don't support. I changed them > from MODE_FOO to MODE_FOOx so any use would break at compile time and > we would fix it. That was back in April. I'm just now seeing this error. > My best guess is that you have only half updated your system. You > have a new ntpmon but it is using an old pylib/magic.py You can see I have the new one installed: pi4 ~ # find / -xdev -name magic.py -exec ls -l {} \; -rw-r--r-- 1 root root 4557 Aug 11 19:43 /usr/local/lib/python3.7/site-packages/ntp/magic.py -rw-r--r-- 1 root root 4557 Feb 24 12:55 /usr/local/lib/python2.7/site-packages/ntp/magic.py -rw-r--r-- 1 root root 4557 Aug 11 18:33 /usr/local/lib/python3.6/site-packages/ntp/magic.py -rw-r--r-- 1 root root 4557 Sep 25 2017 /usr/local/src/NTP/ntpsec/pylib/magic.py -rw-r--r-- 1 root root 4557 Aug 11 19:43 /usr/local/src/NTP/ntpsec/build/main/pylib/magic.py pi4 ~ # python -V Python 3.7.8 pi4 ~ # echo $PYTHONPATH /usr/local/lib/python3.7/site-packages RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Wed Aug 12 20:03:01 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 12 Aug 2020 13:03:01 -0700 Subject: 'MODE_BROADCASTx' Message-ID: <20200812200301.A23EF40605C@ip-64-139-1-69.sjc.megapath.net> > You can see I have the new one installed: Then either the new one is buggy or you aren't using it at runtime. All the magic.py-s that you ls-ed have the same length. That's suspicious. I have 3 different lengths but none of them match yours. -rw-r--r-- 1 root root 4229 Sep 15 2019 /usr/local/lib64/python2.7/site-packag es/ntp/magic.py -rw-r--r-- 1 root root 4309 Apr 25 17:16 /usr/local/lib64/python3.7/site-packag es/ntp/magic.py -rw-r--r-- 1 root root 4337 Aug 6 14:46 /usr/local/lib64/python3.8/site-packag es/ntp/magic.py MODE_BROADCASTx comes from include/ntp.h magic.py is made by a script. It just copies the right chunks from ntp.h and changes #define xx yy to xx = yy. (or something close to that) You can easily check to see if your magic.py has MODE_BROADCASTx or the old MODE_BROADCAST (without the x). Did you do a clean build after git pull? If not, then maybe waf wasn't smart to rebuild magic.py (I use a script to do configure and build, starting with rm -r build.) -- These are my opinions. I hate spam. From gem at rellim.com Wed Aug 12 23:04:04 2020 From: gem at rellim.com (Gary E. Miller) Date: Wed, 12 Aug 2020 16:04:04 -0700 Subject: 'MODE_BROADCASTx' In-Reply-To: <20200812200301.A23EF40605C@ip-64-139-1-69.sjc.megapath.net> References: <20200812200301.A23EF40605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20200812160404.1ae6003b@rellim.com> Yo Hal! On Wed, 12 Aug 2020 13:03:01 -0700 Hal Murray wrote: > > You can see I have the new one installed: > > Then either the new one is buggy or you aren't using it at runtime. Which does not narrow it down much. > magic.py is made by a script. It just copies the right chunks from > ntp.h and changes #define xx yy to xx = yy. (or something close to > that) You can easily check to see if your magic.py has > MODE_BROADCASTx or the old MODE_BROADCAST (without the x). It had the old one: build/main/ntpclients/ntp/magic.py:MODE_BROADCAST = 5 # broadcast mode > Did you do a clean build after git pull? ./waf clean ./waf configure --refclock=all && ./waf build &&./waf install > If not, then maybe waf > wasn't smart to rebuild magic.py Maybe so. I did a complete "rm -R ntpsec" and git clone. Which I thought I had done already, and now it works. So maybe the c;ean is a problem? My previous file times would also indicate that. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From rlaager at wiktel.com Thu Aug 13 03:28:34 2020 From: rlaager at wiktel.com (Richard Laager) Date: Wed, 12 Aug 2020 22:28:34 -0500 Subject: [security@ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec? In-Reply-To: References: <159405814141.176039.269790536430276664.reportbug@hullmann.westfalen.local> Message-ID: I don't think I ever got an answer on this one. On 7/6/20 11:28 PM, Richard Laager via security wrote: > Another NTP CVE (which is already public)... does this affect NTPsec? > > On 7/6/20 12:55 PM, Moritz Muehlenhoff wrote: >> This was assigned CVE-2020-13817 for ntp.org: >> http://support.ntp.org/bin/view/Main/NtpBug3596 >> https://bugs.ntp.org/show_bug.cgi?id=3596 >> http://bk.ntp.org/ntp-stable/?PAGE=patch&REV=5e312021VVVkyioYBR_aeIP1LqMCVg >> http://bk.ntp.org/ntp-stable/?PAGE=patch&REV=5e4a536dzxRWAzMw-KsKjm04l6joNA -- Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rlaager at wiktel.com Thu Aug 13 05:31:39 2020 From: rlaager at wiktel.com (Richard Laager) Date: Thu, 13 Aug 2020 00:31:39 -0500 Subject: ntp in /etc/services In-Reply-To: <20200812094427.452F040605C@ip-64-139-1-69.sjc.megapath.net> References: <20200812094427.452F040605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: On 8/12/20 4:44 AM, Hal Murray via devel wrote: >> Is that a bug, or should I remove that chunk of text? > > That doesn't seem very clear. Let me try again. > > The documentation mentions /etc/services > The current code doesn't use it. It passes "123" rather than "ntp" to the DNS > lookup routines. > > How should we fix that? > 1) fix documentation (easy, remove 2 lines) > 2) change code to use /etc/services #1 please. There's no need to use /etc/services and that's not a common thing for daemons these days to require. With my Debian packager hat on, getting a port in Debian's /etc/services is another level of complication that I don't want to have to deal with. -- Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From Stromeko at nexgo.de Thu Aug 13 05:47:52 2020 From: Stromeko at nexgo.de (ASSI) Date: Thu, 13 Aug 2020 07:47:52 +0200 Subject: ntp in /etc/services In-Reply-To: (Richard Laager via devel's message of "Thu, 13 Aug 2020 00:31:39 -0500") References: <20200812094427.452F040605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <87h7t7qepj.fsf@Otto.invalid> Richard Laager via devel writes: > With my Debian packager hat on, getting a port in Debian's /etc/services > is another level of complication that I don't want to have to deal with. Not to mention that /etc/services has gone away in some distributions recently (moved to /usr/etc/services) and you will have to use nsswitch.conf either directly or indirectly to figure out whether you should use it at all. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra From hmurray at megapathdsl.net Thu Aug 13 10:48:26 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 13 Aug 2020 03:48:26 -0700 Subject: [security@ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec? Message-ID: <20200813104826.8B0F140605C@ip-64-139-1-69.sjc.megapath.net> > I don't think I ever got an answer on this one. It looks familiar, but I can't find any old mail that matches up. I'm probably confusing it with a similar problem. ---------- >> https://bugs.ntp.org/show_bug.cgi?id=3596 That bug talks about feeding bogus time to a system by guessing the transmit time stamp. When ntpd gets a response, it drops responses where the time-stamp it sent doesn't match the corresponding slot in the reply. The idea is that most of the bits in that slot are predictable so an off path attacker has a good chance of getting a bogus response through by guessing the value the server is expecting. There is a draft in the pipeline: https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04 We implement that. I don't know if the authors considered this particular case, but they covered it. We send a random value in that slot (and keep the time in our back pocket) so similar attacks are unlikley to work. -- These are my opinions. I hate spam. From jamesb.fe80 at gmail.com Thu Aug 13 12:49:44 2020 From: jamesb.fe80 at gmail.com (James Browning) Date: Thu, 13 Aug 2020 05:49:44 -0700 Subject: [security@ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec? In-Reply-To: References: <159405814141.176039.269790536430276664.reportbug@hullmann.westfalen.local>

Message-ID: On Wed, Aug 12, 2020, 8:28 PM Richard Laager via devel wrote: > > I don't think I ever got an answer on this one. flattened from listed website[0]: >> Mitigation: >> >> Have enough trustworthy sources of time. >> If you are serving time to a possibly hostile network, have your system get its time from other than unauthenticated IPv4 over the hostile network. >> Use NTP packet authentication where appropriate. >> Pay attention to error messages logged by ntpd. >> Monitor your ntpd instances. If the pstats command of ntpq shows the value for "bogus origin" is increasing then that association is likely under attack. >> If you must get unauthenticated time over IPv4 on a hostile network: >> >> Use restrict ... noserve to prevent this attack (note that this is a heavy-handed protection), which blocks time service to the specified network. >> Upgrade to 4.2.8p14, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page, and appropriately use some or all of the following in your ntp.conf file: >> >> server ... xmtnonce >> pool ... xmtnonce >> restrict ... serverresponse fuzz >> pollskewlist default 6|6 (for example) Defaults to no servers, but supports draft NTS instead of autokey, does not enforce authentication or operator attention, does not support random nonce[1] instead of 4.2.8p14 'features'[0], supports refclock-only time setting for some refclocks. I think we could do more to address this 'client-side' issue. Possible mitigations would include the new features from 4.2.8p14, defaulting to larger minsane, minclock and maxclock values, as well as defaulting to "pool 2.ntpsec.pool.ntp.org" for time. Also, moving the client-side listener [2] might make it harder to spoof answers to the client-side. I am probably wrong about much of this though. [0] http://support.ntp.org/bin/view/Main/NtpBug3596 [1] https://www.ietf.org/archive/id/draft-ietf-ntp-data-minimization-04.txt [2] https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/?include_text=1 From rlaager at wiktel.com Fri Aug 14 08:52:58 2020 From: rlaager at wiktel.com (Richard Laager) Date: Fri, 14 Aug 2020 03:52:58 -0500 Subject: [security@ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec? In-Reply-To: <20200813104826.8B0F140605C@ip-64-139-1-69.sjc.megapath.net> References: <20200813104826.8B0F140605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <60328cef-1982-bb9f-8a80-c5e83c5859d5@wiktel.com> On 8/13/20 5:48 AM, Hal Murray via devel wrote: >>> https://bugs.ntp.org/show_bug.cgi?id=3596 > > That bug talks about feeding bogus time to a system by guessing the transmit > time stamp. > > When ntpd gets a response, it drops responses where the time-stamp it sent > doesn't match the corresponding slot in the reply. The idea is that most of > the bits in that slot are predictable so an off path attacker has a good > chance of getting a bogus response through by guessing the value the server is > expecting. > > There is a draft in the pipeline: > https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04 > We implement that. There is also this (which you forwarded to this list) which might help: https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/ What's the status of that in NTPsec? I presume "not implemented", but is it planned? -- Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Fri Aug 14 09:45:21 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 14 Aug 2020 02:45:21 -0700 Subject: [security@ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec? Message-ID: <20200814094521.9BB6E40605C@ip-64-139-1-69.sjc.megapath.net> > There is also this (which you forwarded to this list) which might help: > https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/ > What's the status of that in NTPsec? I presume "not implemented", but is it > planned? Correct on the "not implemented". I have no plans. It's not hard, but it's not easy. Ballpark of a weekend if there weren't any interruptions. I was ignoring it until the NTS RFC comes out. -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Sat Aug 15 09:59:03 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 15 Aug 2020 02:59:03 -0700 Subject: Locating NTS-KE and NTP servers Message-ID: <20200815095903.43AFD40605C@ip-64-139-1-69.sjc.megapath.net> This area is a tangle. I'm looking for ideas. The context for thinking about this is that several NTS-KE servers have more than one IP Address. I'd like to be able to test all of them and/or maybe use more than one. Let's start with the simple case - no NTS. There are a few NTP servers with names that return multiple IP Addresses. I'd like to be able to test all of those too. Fortunately, we can do that by specifying their individual numerical IP Addresses. But a cleaner approach almost works. If foo has several addresses, it should be reasonable to say server foo server foo and have the code that processes the DNS answers skip over the ones that are already in use. Currently, that doesn't work because configpeers kicks out duplicates. I think the skip-in-use code is there -- or maybe it's over in the pool case. I'll investigate removing that check. --------- There are several unimplemented nts server options: ask, require expire cert Should we remove them, mostly to clean up the documentation? --------- Maybe there should be a mode so things work similarly to pool: setup servers for all IP Addresses that come back from DNS lookup. But do it only once. (pool mode tries again if it needs more servers) --------- Do we need something like the expire option to check DNS again? -- These are my opinions. I hate spam. From rlaager at wiktel.com Sat Aug 15 21:42:12 2020 From: rlaager at wiktel.com (Richard Laager) Date: Sat, 15 Aug 2020 16:42:12 -0500 Subject: Locating NTS-KE and NTP servers In-Reply-To: <20200815095903.43AFD40605C@ip-64-139-1-69.sjc.megapath.net> References: <20200815095903.43AFD40605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <3aa1ec68-fdbd-ed99-9bcc-514a1b2ad4d2@wiktel.com> On 8/15/20 4:59 AM, Hal Murray via devel wrote: > Let's start with the simple case - no NTS. There are a few NTP servers with > names > that return multiple IP Addresses. I'd like to be able to test all of those > too. Fortunately, we can do that by specifying their individual numerical IP > Addresses. > > But a cleaner approach almost works. If foo has several addresses, it should > be reasonable to say > server foo > server foo I'm not 100% certain I follow what you are trying to do, but... could you just use "pool foo"? -- Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Thu Aug 20 08:16:17 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 20 Aug 2020 01:16:17 -0700 Subject: Unimplemented nts options Message-ID: <20200820081617.CA270406060@ip-64-139-1-69.sjc.megapath.net> There are several unimplemented nts server options: ask, require expire cert Unless somebody objects, I'm to remove them. -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Tue Aug 25 23:54:54 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 25 Aug 2020 16:54:54 -0700 Subject: Your recent switch to use pthread_setschedparam Message-ID: <20200825235454.9DE8E40605C@ip-64-139-1-69.sjc.megapath.net> Is inside an #ifdef HAVE_SCHED_SETSCHEDULER -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Wed Aug 26 00:03:55 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 25 Aug 2020 17:03:55 -0700 Subject: Has anybody seen a system without STA_NANO? Message-ID: <20200826000355.46A1D40605C@ip-64-139-1-69.sjc.megapath.net> When was clock_gettime and struct timespec introduced? We can cleanup some cruft if we assume it exists. -- These are my opinions. I hate spam. From dfoxfranke at gmail.com Wed Aug 26 00:08:20 2020 From: dfoxfranke at gmail.com (Daniel Franke) Date: Tue, 25 Aug 2020 20:08:20 -0400 Subject: Has anybody seen a system without STA_NANO? In-Reply-To: <20200826000355.46A1D40605C@ip-64-139-1-69.sjc.megapath.net> References: <20200826000355.46A1D40605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: It's present on Linux, FreeBSD, NetBSD, and Darwin. It's absent on Solaris and IllumOS. On Tue, Aug 25, 2020 at 8:03 PM Hal Murray via devel wrote: > > > When was clock_gettime and struct timespec introduced? > > We can cleanup some cruft if we assume it exists. > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > devel mailing list > devel at ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel From hmurray at megapathdsl.net Wed Aug 26 00:29:32 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 25 Aug 2020 17:29:32 -0700 Subject: Should we check permissions on files that should be secret? Message-ID: <20200826002932.3CE6F40605C@ip-64-139-1-69.sjc.megapath.net> There are 3 files I can think of. Did I miss any? The keys file for shared key authentication. The NTS private key for the server certificate The NTS key file for making/decoding cookies We need to be able to write the cookie file. The others can be (should be?) read only. Things may be slightly complicated with switching to user ntp. -------- There is a related tangle. We want to switch to the log file as early as possible, probably before switching to user ntp. I think logrotate and friends copy the owner and mode. After a fresh install, the log file gets created by user root but ntpd won't be able to open the new file on a SIGHUP. Once you manually set the owner to ntp, things are good. Should we set the owner to ntp (if needed) before switching to ntp? -- These are my opinions. I hate spam. From esr at thyrsus.com Wed Aug 26 00:49:19 2020 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Aug 2020 20:49:19 -0400 Subject: Has anybody seen a system without STA_NANO? In-Reply-To: <20200826000355.46A1D40605C@ip-64-139-1-69.sjc.megapath.net> References: <20200826000355.46A1D40605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20200826004919.GB9161@thyrsus.com> Hal Murray via devel : > > When was clock_gettime and struct timespec introduced? > > We can cleanup some cruft if we assume it exists. Assune it. These are in the Single Unix Standard. -- Eric S. Raymond From dfoxfranke at gmail.com Wed Aug 26 00:49:38 2020 From: dfoxfranke at gmail.com (Daniel Franke) Date: Tue, 25 Aug 2020 20:49:38 -0400 Subject: Has anybody seen a system without STA_NANO? In-Reply-To: <20200826004919.GB9161@thyrsus.com> References: <20200826000355.46A1D40605C@ip-64-139-1-69.sjc.megapath.net> <20200826004919.GB9161@thyrsus.com> Message-ID: clock_gettime is. Adjtimex isn't in any standard except for an obscure RFC that nobody follows. On Tue, Aug 25, 2020, 20:47 Eric S. Raymond via devel wrote: > Hal Murray via devel : > > > > When was clock_gettime and struct timespec introduced? > > > > We can cleanup some cruft if we assume it exists. > > Assune it. These are in the Single Unix Standard. > -- > Eric S. Raymond > > > _______________________________________________ > devel mailing list > devel at ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmurray at megapathdsl.net Wed Aug 26 01:15:15 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 25 Aug 2020 18:15:15 -0700 Subject: Has anybody seen a system without STA_NANO? In-Reply-To: Message from "Eric S. Raymond" of "Tue, 25 Aug 2020 20:49:19 EDT." <20200826004919.GB9161@thyrsus.com> Message-ID: <20200826011515.7689E40605C@ip-64-139-1-69.sjc.megapath.net> > We can cleanup some cruft if we assume it exists. My "it" referred to STA_NANO rather than clock_gettime and struct timespec I was just assuming that most systems would have added STA_NANO where appropriate after they implemented nanosecond timekeeping and struct timespec. Of course, a system doesn't actually need nanosecond timekeeping in order to support clock_gettime. A library wrapper could multiply by 1000. -- These are my opinions. I hate spam. From esr at thyrsus.com Wed Aug 26 01:20:40 2020 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 25 Aug 2020 21:20:40 -0400 Subject: Has anybody seen a system without STA_NANO? In-Reply-To: References: <20200826000355.46A1D40605C@ip-64-139-1-69.sjc.megapath.net> <20200826004919.GB9161@thyrsus.com> Message-ID: <20200826012040.GA10427@thyrsus.com> Daniel Franke : > clock_gettime is. Adjtimex isn't in any standard except for an obscure RFC > that nobody follows. > > On Tue, Aug 25, 2020, 20:47 Eric S. Raymond via devel > wrote: > > > Hal Murray via devel : > > > > > > When was clock_gettime and struct timespec introduced? > > > > > > We can cleanup some cruft if we assume it exists. > > > > Assune it. These are in the Single Unix Standard. Hal, were you asking about adjtimex? Because struct timespec isn't what adjtimex works with - it's associat4d wuj clock_gettime(). -- Eric S. Raymond From folkert at vanheusden.com Sat Aug 29 10:44:05 2020 From: folkert at vanheusden.com (folkert) Date: Sat, 29 Aug 2020 12:44:05 +0200 Subject: bug in /usr/bin/ntpdig Message-ID: <20200829104405.GG13457@belle.intranet.vanheusden.com> Hi, /usr/bin/ntpdig -j -p 8 produces an invalid json string: {"time":"2020-08-29T12:37:41.817391-0200","offset":-0.000034,"precision":0.000158,"host":"localhost",ip:"::1","stratum":1,"leap":"no-leap","adjusted":false} As you can see here, the " before ip: is missing and also the 2nd " is misplaced. Patch: --- /tmp/ntpdig.org 2020-08-29 12:40:27.846037478 +0200 +++ /usr/bin/ntpdig 2020-08-29 12:43:29.106035763 +0200 @@ -216,7 +216,7 @@ if json: say('{"time":"%sT%s%s","offset":%f,"precision":%f,"host":"%s",' - 'ip:"%s","stratum":%s,"leap":"%s","adjusted":%s}\n' + '"ip":"%s","stratum":%s,"leap":"%s","adjusted":%s}\n' % (date, tod, tz, packet.adjust(), packet.synchd(), packet.hostname, packet.resolved or packet.hostname, Folkert van Heusden -- MultiTail er et flexible tool for ? kontrolere Logfiles og commandoer. Med filtrer, farger, sammenf?ringer, forskeliger ansikter etc. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From hmurray at megapathdsl.net Sat Aug 29 18:58:35 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 29 Aug 2020 11:58:35 -0700 Subject: How about a release soon? Message-ID: <20200829185835.2996C40605C@ip-64-139-1-69.sjc.megapath.net> The RFC isn't out yet and I have no idea when it will get published. I'd like to get an official release out that uses port 4460. The current code still listens on port 123 as well as 4460. I'd like to remove that when the RFC comes out and we release 1.2 -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Sun Aug 30 00:02:02 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 29 Aug 2020 17:02:02 -0700 Subject: Anybody running macOS 11.0 (Big Sur) beta Message-ID: <20200830000202.E88EA40605C@ip-64-139-1-69.sjc.megapath.net> If our tests don't cover this case, we probably should. Subject: [chrony-dev] [PATCH] macOS 11.0 (Big Sur) beta - Bug in implementation of ntp_adjtime() From: Bryan Christianson Date: Sun, 30 Aug 2020 09:49:22 +1200 To: chrony-dev at chrony.tuxfamily.org Cc: Bryan Christianson macOS 11.0 (Big Sur) beta incorrectly returns timex.freq as an unsigned number. This patch is a workaround for the bug and should be removed when Apple fix the problem (assuming they will). The patch also extends the ntpadjtime test to cover negative frequencies. --- sys_timex.c | 23 +++++++++++++++++++++-- test/kernel/ntpadjtime.c | 2 +- 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/sys_timex.c b/sys_timex.c index 0a6b438..aa1508a 100644 --- a/sys_timex.c +++ b/sys_timex.c @@ -68,6 +68,25 @@ static int sys_tai_offset; /* ================================================== */ +static inline double +txc_freq(const struct timex *txc) +{ + double freq_ppm; + + freq_ppm = txc->freq / FREQ_SCALE; + +#ifdef MACOSX + /* temporary work-around for Apple bug treating freq as unsigned number */ + if (freq_ppm > 32767) { + freq_ppm -= 65536; + } +#endif + + return -freq_ppm; +} + +/* ================================================== */ + static double read_frequency(void) { @@ -77,7 +96,7 @@ read_frequency(void) SYS_Timex_Adjust(&txc, 0); - return txc.freq / -FREQ_SCALE; + return txc_freq(&txc); } /* ================================================== */ @@ -92,7 +111,7 @@ set_frequency(double freq_ppm) SYS_Timex_Adjust(&txc, 0); - return txc.freq / -FREQ_SCALE; + return txc_freq(&txc); } /* ================================================== */ diff --git a/test/kernel/ntpadjtime.c b/test/kernel/ntpadjtime.c index d6be154..96c069f 100644 --- a/test/kernel/ntpadjtime.c +++ b/test/kernel/ntpadjtime.c @@ -52,7 +52,7 @@ test_freqrange(void) printf("freq range:\n"); - for (i = 0; i <= 1000; i += 50) { + for (i = -1000; i <= 1000; i += 50) { t.modes = MOD_FREQUENCY; t.freq = i << 16; printf("%4d ppm => ", i); -- 2.24.3 (Apple Git-128) -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Sun Aug 30 17:12:03 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Sun, 30 Aug 2020 10:12:03 -0700 Subject: cpp hacking: bump FOO by 1 Message-ID: <20200830171203.5294540605C@ip-64-139-1-69.sjc.megapath.net> Is there any way to do something like #define FOO $FOO+1 I want to keep track of the number of times a macro has been called. That seems like something that would happen often enough that there would be a standard recipe but I haven't seen it. (Or didn't recognize it.) ---------- The context is the code in ntp_control that is responding to ntpq requests to read a variable. It needs to translate a string (name of variable to read) to a subroutine to print that variable. Current code looks like: #define CS_REFID 6 { CS_REFID, RO|DEF, "refid" }, #define CS_REFTIME 7 { CS_REFTIME, RO|DEF, "reftime" }, #define CS_POLL 8 { CS_POLL, RO|DEF, "tc" }, #define CS_PEERID 9 { CS_PEERID, RO|DEF, "peer" }, That sets up the table to search. The table is big (~100 slots) so it's a real pain to insert a new slot. Later on, there is a giant select that uses those CS_xxx tags: case CS_ROOTDELAY: ctl_putdbl(sys_var[CS_ROOTDELAY].text, sys_vars.sys_rootdelay * MS_PER_S); break; case CS_ROOTDISPERSION: ctl_putdbl(sys_var[CS_ROOTDISPERSION].text, sys_vars.sys_rootdisp * MS_PER_S); break; --------- One approach would be to have an external program do the equivalent of the cpp processing that we would like to do. That would take some waf hacking, but shouldn't be a big deal. -- These are my opinions. I hate spam. From Stromeko at nexgo.de Sun Aug 30 18:26:27 2020 From: Stromeko at nexgo.de (ASSI) Date: Sun, 30 Aug 2020 20:26:27 +0200 Subject: cpp hacking: bump FOO by 1 In-Reply-To: <20200830171203.5294540605C@ip-64-139-1-69.sjc.megapath.net> (Hal Murray via devel's message of "Sun, 30 Aug 2020 10:12:03 -0700") References: <20200830171203.5294540605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <87k0xgat2k.fsf@Otto.invalid> Hal Murray via devel writes: > I want to keep track of the number of times a macro has been called. That > seems like something that would happen often enough that there would be a > standard recipe but I haven't seen it. (Or didn't recognize it.) You seem to be asking for the non-portable __COUNTER__ macro. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds From hmurray at megapathdsl.net Sun Aug 30 21:52:47 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Sun, 30 Aug 2020 14:52:47 -0700 Subject: coding style - statistics Message-ID: <20200830215247.A2A7740605C@ip-64-139-1-69.sjc.megapath.net> Context is that James is working on making ntpq/sysstats (and friends) print out the totals for counters as a second column next to the since-reset that it currently prints. The current counters get reset if/when they are logged hourly so ntpq can't see the big picture after the system has been up for a while. Currently, we have a blizzard of things like: extern uint64_t stat_received(void); and uint64_t stat_received(void) { return stat_count.sys_received; } I know that's the "right" way to do it, but it seems like a lot of unnecessary clutter to me. It took me a while to figure out why I think that way. A procedure would be the clean way to access a simple variable if that was a public API that we expected to support for many clients and a long time. Doubly so if the data is in a struct. But we don't have any external clients and we rebuild everything when we change the struct. To me, the clutter isn't worth it. Each slot is only used in a few places. The clutter adds 2 more. Does anybody have strong opinions? (I can live with the clutter, it's just not the way I would do it.) ---------- I'm thinking of making a new header and module: ntp_stats. The idea is to collect the structs that hold the counters, the code that does the logging and resets, and the new code that merges the about-to-be-reset counters into a second struct. If people think the procedures are the way to go, I'll have to add one to bump each counter. -- These are my opinions. I hate spam. From mark.atwood at ntpsec.org Mon Aug 31 16:26:08 2020 From: mark.atwood at ntpsec.org (Mark Atwood) Date: Mon, 31 Aug 2020 09:26:08 -0700 Subject: How about a release soon? In-Reply-To: <20200829185835.2996C40605C@ip-64-139-1-69.sjc.megapath.net> References: <20200829185835.2996C40605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <939f3644-d0ad-4c3c-9ff2-4979a5259245@www.fastmail.com> HI, I've been waiting as well on the RFC for 1.2 Has there been enough user visible improvement to warrent a release of 1.1.10? ..m ..??? Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 On Sat, Aug 29, 2020, at 11:58, Hal Murray wrote: > > The RFC isn't out yet and I have no idea when it will get published. > > I'd like to get an official release out that uses port 4460. > > The current code still listens on port 123 as well as 4460. I'd like to > remove that when the RFC comes out and we release 1.2 > > > > -- > These are my opinions. I hate spam. > > > > From hmurray at megapathdsl.net Mon Aug 31 18:36:06 2020 From: hmurray at megapathdsl.net (Hal Murray) Date: Mon, 31 Aug 2020 11:36:06 -0700 Subject: How about a release soon? In-Reply-To: Message from "Mark Atwood" of "Mon, 31 Aug 2020 09:26:08 PDT." <939f3644-d0ad-4c3c-9ff2-4979a5259245@www.fastmail.com> Message-ID: <20200831183606.AE6F140605C@ip-64-139-1-69.sjc.megapath.net> > Has there been enough user visible improvement to warrent a release of 1.1.10? I think so. 1.1.9 doesn't know about the new port number for NTS-KE. There is also a bug fix for a missing error message. Without that message, it's really tough to debug an obscure case of certificates not working. -- These are my opinions. I hate spam.