From halmurray at sonic.net Sun Dec 3 04:09:00 2023 From: halmurray at sonic.net (Hal Murray) Date: Sat, 02 Dec 2023 20:09:00 -0800 Subject: Release Message-ID: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> I think you should release what we have as soon as it is convenient. There are many more things I would like to include but we aren't making much progress so it's time to do it. -- These are my opinions. I hate spam. From jamesb192 at jamesb192.com Sun Dec 3 05:12:04 2023 From: jamesb192 at jamesb192.com (James Browning) Date: Sat, 2 Dec 2023 21:12:04 -0800 (PST) Subject: Release In-Reply-To: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <420330176.21824.1701580324056@privateemail.com> > On 12/02/2023 8:09 PM PST Hal Murray via devel wrote: > > > I think you should release what we have as soon as it is convenient. > > There are many more things I would like to include but we aren't making much > progress so it's time to do it. Referring to the first four items on the release checklist. 1. It is approximately time for a release. 4. The buildbots are not reporting any unplanned regressions; there are always issues to be addressed. 2a. An early warning has been sent to the devel list. The NEWS and devel/TODO files are not up to date. 2b. There have been 144 commits since 1.2.2; 53 are from Hal Murray, 47 are from Matt Selsky, 31 are from James Browning, and everyone else totals 13. 3. I think we should nix the devel/TODO* files and update the NEWS file before cutting a release, but I do not see any other major blockers to a soon(ish) release. From halmurray at sonic.net Sun Dec 3 09:22:35 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 03 Dec 2023 01:22:35 -0800 Subject: Certificate geekery Message-ID: <20231203092235.9FCF628C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> I'm working on devel-TODO-NTS. (mostly deleting things) Currently, if a bad guy hacks or arm-twists a certificate authority, they can sign a certificate that the bad guy can use for a MITM attack. We can make that a lot harder if we lookup the current root certificate that a server is currently using, find that certificate in a system's root cert collection, and add a ca xxx to the server line. That doesn't take any changes to ntpd. It needs some script hacking. I think the openssl command can handle much of the details. Is that called pinning? If not, is there a term for it? Wiki has a page for a related proposal: https://en.wikipedia.org/wiki/Certificate_pinning Is this interesting? Anybody interested in writing that script? ------ There is another tangle with verifying certificates. OCSP Is that interesting? https://en.wikipedia.org/wiki/OCSP -- These are my opinions. I hate spam. From gem at rellim.com Sun Dec 3 22:21:54 2023 From: gem at rellim.com (Gary E. Miller) Date: Sun, 3 Dec 2023 14:21:54 -0800 Subject: Release In-Reply-To: <420330176.21824.1701580324056@privateemail.com> References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <420330176.21824.1701580324056@privateemail.com> Message-ID: <20231203142154.3af7e2b6@spidey.rellim.com> Yo James! On Sat, 2 Dec 2023 21:12:04 -0800 (PST) James Browning via devel wrote: > 4. The buildbots are not reporting any unplanned regressions; there > are always issues to be addressed. Uh, not quite. Check the Coverity stuff. 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: 246 bytes Desc: OpenPGP digital signature URL: From halmurray at sonic.net Sun Dec 3 23:07:18 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 03 Dec 2023 15:07:18 -0800 Subject: Release Message-ID: <20231203230718.7E1A128C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Gary said: > Uh, not quite. Check the Coverity stuff. How do I do that? I'd expect something to send me email but I don't remember anything about Coverity. -- These are my opinions. I hate spam. From gem at rellim.com Mon Dec 4 00:43:38 2023 From: gem at rellim.com (Gary E. Miller) Date: Sun, 3 Dec 2023 16:43:38 -0800 Subject: Release In-Reply-To: <20231203230718.7E1A128C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231203230718.7E1A128C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <20231203164338.6652b91a@spidey.rellim.com> Yo Hal! On Sun, 03 Dec 2023 15:07:18 -0800 Hal Murray via devel wrote: > Gary said: > > Uh, not quite. Check the Coverity stuff. > > How do I do that? DO you have an account on: https://scan.coverity.com/ If so, I think I can add you to the project. 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: 246 bytes Desc: OpenPGP digital signature URL: From gem at rellim.com Mon Dec 4 00:50:25 2023 From: gem at rellim.com (Gary E. Miller) Date: Sun, 3 Dec 2023 16:50:25 -0800 Subject: Release In-Reply-To: <20231203164338.6652b91a@spidey.rellim.com> References: <20231203230718.7E1A128C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <20231203164338.6652b91a@spidey.rellim.com> Message-ID: <20231203165025.5febdd3c@spidey.rellim.com> Yo Hal! On Sun, 03 Dec 2023 15:07:18 -0800 Hal Murray via devel wrote: > > Gary said: > > > Uh, not quite. Check the Coverity stuff. > > > > How do I do that? > > DO you have an account on: https://scan.coverity.com/ On further checking, halmurray+cv at sonic.net is an admin on the NTPSec Coverity account. 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: 246 bytes Desc: OpenPGP digital signature URL: From halmurray at sonic.net Mon Dec 4 01:44:45 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 03 Dec 2023 17:44:45 -0800 Subject: Release Message-ID: <20231204014445.764EC28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Gary said: > DO you have an account on: https://scan.coverity.com/ > If so, I think I can add you to the project. Thanks. I think i worked. How does their stuff work? How often do they check NTPsec? Or what should I be asking? How much mail should I expect? ... There are 3 Coverity quirks. I'll go fix the filegen one. Should I push the fix? That will require more testing. -- These are my opinions. I hate spam. From gem at rellim.com Mon Dec 4 01:56:22 2023 From: gem at rellim.com (Gary E. Miller) Date: Sun, 3 Dec 2023 17:56:22 -0800 Subject: Release In-Reply-To: <20231204014445.764EC28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231204014445.764EC28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <20231203175622.1b3373f1@spidey.rellim.com> Yo Hal! On Sun, 03 Dec 2023 17:44:45 -0800 Hal Murray via devel wrote: > Gary said: > > DO you have an account on: https://scan.coverity.com/ > > If so, I think I can add you to the project. > > How does their stuff work? How often do they check NTPsec? > Or what should I be asking? Every time a commit is made to NTPSec on GitLab, the CI asks Coverity to do a review. > How much mail should I expect? ... One email every few commits. > Should I push the fix? That will require more testing. Or you could do an MR that we can test first. All depends on how good you feel about the commit. 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: 246 bytes Desc: OpenPGP digital signature URL: From halmurray at sonic.net Mon Dec 4 02:49:30 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 03 Dec 2023 18:49:30 -0800 Subject: Asciidoc question Message-ID: <20231204024930.7F95628C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> What does the $$ after the +aga+ do? |+year+ |One generation file element is generated per year. The filename suffix consists of a dot and a 4 digit year number. |+age+$$ |This type of file generation sets changes to a new element of the file set every 24 hours of server operation. The filename -- These are my opinions. I hate spam. From jamesb192 at jamesb192.com Mon Dec 4 03:05:48 2023 From: jamesb192 at jamesb192.com (James Browning) Date: Sun, 03 Dec 2023 19:05:48 -0800 Subject: Asciidoc question In-Reply-To: <20231204024930.7F95628C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <3cf06b8c-3157-45b4-9275-dbb61349d6fa@email.android.com> An HTML attachment was scrubbed... URL: From halmurray at sonic.net Mon Dec 4 07:45:40 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 03 Dec 2023 23:45:40 -0800 Subject: How does the parser work? Message-ID: <20231204074540.24E0328C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> ntp_parser.y contqains: %token T_Tinker %token T_Tlsciphers %token T_Tlsciphersuites I'd expect those tokens to come from the keywords header file. But tlsciphers isn't in the keyword list. tlscipehrswuites is in the list. -- These are my opinions. I hate spam. From rlaager at wiktel.com Mon Dec 4 18:11:45 2023 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 4 Dec 2023 12:11:45 -0600 Subject: Certificate geekery In-Reply-To: <20231203092235.9FCF628C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231203092235.9FCF628C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: On 2023-12-03 03:22, Hal Murray via devel wrote: > I'm working on devel-TODO-NTS. (mostly deleting things) > > Currently, if a bad guy hacks or arm-twists a certificate authority, they can > sign a certificate that the bad guy can use for a MITM attack. Yes, that's how the CA ecosystem works. That is absolutely a threat. Keep in mind that if a CA gets caught doing that, they will get the CA death penalty, ending their money printing business. CAA records and Certificate Transparency are also mitigations of this threat. > We can make that a lot harder if we lookup the current root certificate that a > server is currently using, find that certificate in a system's root cert > collection, and add a ca xxx to the server line. That doesn't take any > changes to ntpd. If that's a thing you want to do on your system, you can. IMHO, it's not something that we particularly need to promote, nor would I find it desirable operationally. If my NTP server changes their CA provider, then I won't be able to talk to them any more until I take manual action to adjust the pin. > Is that called pinning? If not, is there a term for it? > Wiki has a page for a related proposal: > https://en.wikipedia.org/wiki/Certificate_pinning It sounds like pinning to me, at least a form of the general idea. -- Richard From jamesb192 at jamesb192.com Mon Dec 4 21:49:45 2023 From: jamesb192 at jamesb192.com (James Browning) Date: Mon, 04 Dec 2023 13:49:45 -0800 Subject: How does the parser work? In-Reply-To: <20231204074540.24E0328C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <78fdc252-14c2-4c53-a646-446264a0cea5@email.android.com> An HTML attachment was scrubbed... URL: From jamesb192 at jamesb192.com Mon Dec 4 22:19:08 2023 From: jamesb192 at jamesb192.com (James Browning) Date: Mon, 04 Dec 2023 14:19:08 -0800 Subject: How does the parser work? In-Reply-To: <78fdc252-14c2-4c53-a646-446264a0cea5@email.android.com> Message-ID: An HTML attachment was scrubbed... URL: From halmurray at sonic.net Mon Dec 4 23:03:52 2023 From: halmurray at sonic.net (Hal Murray) Date: Mon, 04 Dec 2023 15:03:52 -0800 Subject: How does the parser work? In-Reply-To: Message from James Browning via devel of "Mon, 04 Dec 2023 13:49:45 -0800." <78fdc252-14c2-4c53-a646-446264a0cea5@email.android.com> Message-ID: <20231204230352.2784628C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> James said: > The host phase of Waf build generates tablegen which in turn generates > keywords.h IIRC. I have no idea how the internals work. I took a look at the code. It looks like there are 2 tables of keywords, one in ntp_keyword.h (build by keyword-gen) and another in ntp_parser.y. Because the tokens in each table look so similar, my brain jumped to the conclusion that they were parallel. Wrong. The values of the corresponding tokens are different. I don't know how the values from the keyword table get translated into parser values. The parser table also has a few extra entries like integer and string. keyword.h is more than just a list of keywords. It's also table/tree of steps along the way of recognizing a keyword: S_ST( 's', 3, 675, 422 ), /* 674 tru */ S_ST( 't', 3, 676, 0 ), /* 675 trus */ S_ST( 'e', 3, 677, 0 ), /* 676 trust */ S_ST( 'd', 3, 678, 0 ), /* 677 truste */ S_ST( 'k', 3, 679, 0 ), /* 678 trusted */ S_ST( 'e', 3, 423, 0 ), /* 679 trustedk */ Anyway, I think extra "keywords" in the parser table are just useless. The parser will never get there because the keyword table doesn't know about them. When we run out of better things to do, we should make a config file that uses all the keywords so we can make sure they work and are all useful. -- These are my opinions. I hate spam. From Matthew.Selsky at twosigma.com Wed Dec 6 01:56:51 2023 From: Matthew.Selsky at twosigma.com (Matthew Selsky) Date: Wed, 6 Dec 2023 01:56:51 +0000 Subject: Release In-Reply-To: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: On Sat, Dec 02, 2023 at 08:09:00PM -0800, Hal Murray wrote: > > I think you should release what we have as soon as it is convenient. > > There are many more things I would like to include but we aren't making much > progress so it's time to do it. Hi Hal, Sounds good. I'll aim to release ~15-Dec-2023. Can you and others make sure that NEWS is up-to-date, especially for user-facing changes? I'm thinking about AES becoming the new default for ntpq, etc. I'll review this as well. Thanks, -Matt From halmurray at sonic.net Wed Dec 6 03:57:54 2023 From: halmurray at sonic.net (Hal Murray) Date: Tue, 05 Dec 2023 19:57:54 -0800 Subject: Release In-Reply-To: Message from Matthew Selsky of "Wed, 06 Dec 2023 01:56:51 +0000." Message-ID: <20231206035754.EA33D28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> > I'll aim to release ~15-Dec-2023 Sounds good. Thanks. > I'm thinking about AES becoming the new default for ntpq, etc. I got a few a day or so ago. I missed that one. I'll get it tonight. -- These are my opinions. I hate spam. From halmurray at sonic.net Wed Dec 6 04:40:46 2023 From: halmurray at sonic.net (Hal Murray) Date: Tue, 05 Dec 2023 20:40:46 -0800 Subject: Any Coverity wizards? Message-ID: <20231206044046.40D0528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> I expect the comment on the previous line to tell Coverity to not complain about this case. Is there a typo or such that I'm missing? 149 /* coverity[checked_return] */ CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN) 15. check_return: Calling CMAC_Update without checking return value (as is done elsewhere 5 out of 6 times). 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); -- These are my opinions. I hate spam. From halmurray at sonic.net Wed Dec 6 07:45:58 2023 From: halmurray at sonic.net (Hal Murray) Date: Tue, 05 Dec 2023 23:45:58 -0800 Subject: What does gitlab's "Successful pipeline" mean? Message-ID: <20231206074558.EBC2928C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Does that mean no warnings? If not, how are we expected to learn about code that generates warnings on obscure systems? -- These are my opinions. I hate spam. From jamesb192 at jamesb192.com Wed Dec 6 08:08:41 2023 From: jamesb192 at jamesb192.com (James Browning) Date: Wed, 06 Dec 2023 00:08:41 -0800 Subject: What does gitlab's "Successful pipeline" mean? In-Reply-To: <20231206074558.EBC2928C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: An HTML attachment was scrubbed... URL: From halmurray at sonic.net Wed Dec 6 09:25:46 2023 From: halmurray at sonic.net (Hal Murray) Date: Wed, 06 Dec 2023 01:25:46 -0800 Subject: What does gitlab's "Successful pipeline" mean? In-Reply-To: Message from James Browning via devel of "Wed, 06 Dec 2023 00:08:41 -0800." Message-ID: <20231206092546.14FA528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> James said: > Maybe we should add -Werror or such to CFLAGS. Sounds like a good idea to me. -- These are my opinions. I hate spam. From Stromeko at nexgo.de Wed Dec 6 17:55:19 2023 From: Stromeko at nexgo.de (ASSI) Date: Wed, 06 Dec 2023 18:55:19 +0100 Subject: Any Coverity wizards? References: <20231206044046.40D0528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <875y1bw708.fsf@Gerda.invalid> Hal Murray via devel writes: > I expect the comment on the previous line to tell Coverity to not complain > about this case. > > Is there a typo or such that I'm missing? > > 149 /* coverity[checked_return] */ > CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN) > 15. check_return: Calling CMAC_Update without checking return value (as is > done elsewhere 5 out of 6 times). > 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); You might need to cast the return value of the function to void. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds From Stromeko at nexgo.de Wed Dec 6 17:55:19 2023 From: Stromeko at nexgo.de (ASSI) Date: Wed, 06 Dec 2023 18:55:19 +0100 Subject: Any Coverity wizards? References: <20231206044046.40D0528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <875y1bw708.fsf@Gerda.invalid> Hal Murray via devel writes: > I expect the comment on the previous line to tell Coverity to not complain > about this case. > > Is there a typo or such that I'm missing? > > 149 /* coverity[checked_return] */ > CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN) > 15. check_return: Calling CMAC_Update without checking return value (as is > done elsewhere 5 out of 6 times). > 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); You might need to cast the return value of the function to void. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds From Stromeko at nexgo.de Wed Dec 6 17:55:19 2023 From: Stromeko at nexgo.de (ASSI) Date: Wed, 06 Dec 2023 18:55:19 +0100 Subject: Any Coverity wizards? References: <20231206044046.40D0528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <875y1bw708.fsf@Gerda.invalid> Hal Murray via devel writes: > I expect the comment on the previous line to tell Coverity to not complain > about this case. > > Is there a typo or such that I'm missing? > > 149 /* coverity[checked_return] */ > CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN) > 15. check_return: Calling CMAC_Update without checking return value (as is > done elsewhere 5 out of 6 times). > 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); You might need to cast the return value of the function to void. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds From Stromeko at nexgo.de Wed Dec 6 17:55:19 2023 From: Stromeko at nexgo.de (ASSI) Date: Wed, 06 Dec 2023 18:55:19 +0100 Subject: Any Coverity wizards? References: <20231206044046.40D0528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <875y1bw708.fsf@Gerda.invalid> Hal Murray via devel writes: > I expect the comment on the previous line to tell Coverity to not complain > about this case. > > Is there a typo or such that I'm missing? > > 149 /* coverity[checked_return] */ > CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN) > 15. check_return: Calling CMAC_Update without checking return value (as is > done elsewhere 5 out of 6 times). > 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); You might need to cast the return value of the function to void. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds From gem at rellim.com Wed Dec 6 21:33:06 2023 From: gem at rellim.com (Gary E. Miller) Date: Wed, 6 Dec 2023 13:33:06 -0800 Subject: Any Coverity wizards? In-Reply-To: <20231206044046.40D0528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231206044046.40D0528C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <20231206133306.7dc3a7a1@spidey.rellim.com> Yo Hal! On Tue, 05 Dec 2023 20:40:46 -0800 Hal Murray via devel wrote: > I expect the comment on the previous line to tell Coverity to not > complain about this case. > > Is there a typo or such that I'm missing? > > 149 /* coverity[checked_return] */ > CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN) > 15. check_return: Calling CMAC_Update without checking return value > (as is done elsewhere 5 out of 6 times). > 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); AFAIK, that override should work, but does not. Maybe "checked_return" should be in CAPS? The suggestions of adding (void) should work. Ir actually check the return. 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: 246 bytes Desc: OpenPGP digital signature URL: From halmurray at sonic.net Fri Dec 8 04:26:51 2023 From: halmurray at sonic.net (Hal Murray) Date: Thu, 07 Dec 2023 20:26:51 -0800 Subject: Certificate geekery In-Reply-To: Message from Richard Laager via devel of "Mon, 04 Dec 2023 12:11:45 -0600." Message-ID: <20231208042652.04F4D28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Thanks. > If that's a thing you want to do on your system, you can. IMHO, it's not > something that we particularly need to promote, nor would I find it > desirable operationally. If my NTP server changes their CA provider, then I > won't be able to talk to them any more until I take manual action to adjust > the pin. I was assuming there would be a script that would do the work, say run as a cron job. Probably send you email so you can do the actual edit. > Yes, that's how the CA ecosystem works. That is absolutely a threat. Keep in > mind that if a CA gets caught doing that, they will get the CA death > penalty, ending their money printing business. Some CAs are run by governments. That area gets messy. There was a news item recently (month or 3??) about a Russian social media server located in a German cloud provider that got MITM-ed. The bad guys got a Let's Encrypt certificate. They could do that by just stealing the IP Address for a few minutes which only takes one insider at the hosting service. Researchers Uncover Wiretapping of XMPP-Based Instant Messaging Service https://thehackernews.com/2023/10/researchers-uncover-wiretapping-of-xmpp.htm l I can't tell how paranoid to be. It would be nice if we didn't depend on all the root certificates. -- These are my opinions. I hate spam. From Matthew.Selsky at twosigma.com Mon Dec 18 04:15:36 2023 From: Matthew.Selsky at twosigma.com (Matt Selsky) Date: Mon, 18 Dec 2023 04:15:36 +0000 Subject: Release Message-ID: I?ll create a release candidate on Monday 12/18 and then a final release shortly thereafter. Thanks, -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at fwright.net Mon Dec 18 04:17:23 2023 From: fw at fwright.net (Fred Wright) Date: Sun, 17 Dec 2023 20:17:23 -0800 (PST) Subject: Release In-Reply-To: References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: On Wed, 6 Dec 2023, Matthew Selsky via devel wrote: > Sounds good. I'll aim to release ~15-Dec-2023. Fortunately this hasn't happened yet. :-) The main issue I've found is that the "struct var" in ntp_control.c, is relying on anonymous unions, which are a relatively new language feature. They were originally a GNU extension, eventually becoming official in C11. But significantly increasing the compiler requirements just for one table doesn't seem terribly desirable. Turning the "p_" and "p2_" prefixes into names of the union instances seems fairly reasonable (e.g., "p_time" becomes "p.time"), but would require changing the initializers. I'd be willing to look into that if I'm not wasting my time. There are also a bunch of warnings with some compilers, which might be worth looking at. They're often fairly easy to fix, and sometimes indicate actual problems. I also stumbled across something (which may not be new) where it appears that if libaes_siv is installed as a system library, it's preferred over the bundled version. That probably doesn't change the actual behavior, but may lead to opportunistic builds. Fred Wright From halmurray at sonic.net Mon Dec 18 05:49:13 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 17 Dec 2023 21:49:13 -0800 Subject: Release In-Reply-To: Message from Fred Wright via devel of "Sun, 17 Dec 2023 20:17:23 -0800." Message-ID: <20231218054913.C2FDB28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Fred Wright said: > The main issue I've found is that the "struct var" in ntp_control.c, is > relying on anonymous unions, which are a relatively new language feature. That is my attempt at getting a sane procedure for adding slots to the table. The old scheme required coordinated edits in several places and there was no checking that you got them right. > Turning the "p_" and "p2_" prefixes into names of the union instances seems > fairly reasonable (e.g., "p_time" becomes "p.time"), but would require > changing the initializers. I'd be willing to look into that if I'm not > wasting my time. I think I just fixed that. I'll push in a while after more local testing. > There are also a bunch of warnings with some compilers, which might be worth > looking at. They're often fairly easy to fix, and sometimes indicate actual > problems. Which compilers? Or rather which OS/distros? Can we set things up so that the gitlab CI stuff tells us about warnings? James suggested adding the compiler flag that turns warnings into errors. That won't work on the old old version of Bison that has a missing default or something like that. -- These are my opinions. I hate spam. From halmurray at sonic.net Mon Dec 18 07:18:33 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 17 Dec 2023 23:18:33 -0800 Subject: Release In-Reply-To: Message from Fred Wright via devel of "Sun, 17 Dec 2023 20:17:23 -0800." Message-ID: <20231218071833.0EE1928C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Fred Wright said: > I also stumbled across something (which may not be new) where it appears > that if libaes_siv is installed as a system library, it's preferred over the > bundled version. That probably doesn't change the actual behavior, but may > lead to opportunistic builds. That seems worth fixing. I don't think we should hold up the release unless somebody fixes it in the next day or two. -- These are my opinions. I hate spam. From halmurray at sonic.net Mon Dec 18 07:49:05 2023 From: halmurray at sonic.net (Hal Murray) Date: Sun, 17 Dec 2023 23:49:05 -0800 Subject: Missing clockwork Message-ID: <20231218074905.80E6D28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Anybody recognize this? I've seen a missing file once before. I think it was clockwork.?? It works if I try it again. Waf: Entering directory `/home/murray/ntpsec/raw/test-all/main' --- PYTHONPATH is not set, loading the Python ntp library may be troublesome --- [ 1/137] Compiling libntp/clockwork.c [ 2/137] Compiling libaes_siv/aes_siv.c [ 3/137] Compiling libntp/clockwork.c [ 4/137] Compiling libntp/clockwork.c [ 5/137] Compiling libntp/ntp_endian.c [ 6/137] Compiling libntp/macencrypt.c [ 7/137] Compiling libntp/isc_net.c [ 8/137] Compiling libntp/isc_interfaceiter.c [ 9/137] Compiling libntp/initnetwork.c [ 10/137] Compiling libntp/getopt.c [ 11/137] Compiling libntp/timespecops.c Waf: Leaving directory `/home/murray/ntpsec/raw/test-all/main' Build failed -> missing file: '/home/murray/ntpsec/raw/test-all/main/libntp/clockwork.c.1.o' [murray at hgm raw]$ find . -name clockwork* ./test-all/main/libntp/clockwork.c.1.o ./test-minimal/main/libntp/clockwork.c.1.o ./test-minimal/main/libntp/clockwork.c.2.o ./test-classic/main/libntp/clockwork.c.1.o ./test-classic/main/libntp/clockwork.c.2.o ./test-doc/main/libntp/clockwork.c.1.o ./test-doc/main/libntp/clockwork.c.2.o ./libntp/clockwork.c ./hgm/main/libntp/clockwork.c.1.o ./hgm/main/libntp/clockwork.c.2.o ./test-default/main/libntp/clockwork.c.1.o ./test-default/main/libntp/clockwork.c.2.o -- These are my opinions. I hate spam. From jamesb192 at jamesb192.com Mon Dec 18 13:56:19 2023 From: jamesb192 at jamesb192.com (James Browning) Date: Mon, 18 Dec 2023 05:56:19 -0800 (PST) Subject: Missing clockwork In-Reply-To: <20231218074905.80E6D28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231218074905.80E6D28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <1526166741.74531.1702907779236@privateemail.com> > On 12/17/2023 11:49 PM PST Hal Murray via devel wrote: > > > Anybody recognize this? I've seen a missing file once before. I think it was > clockwork.?? > > It works if I try it again. It sounds like a race condition in our wscript files or waf. How willing are you to sink time into this, I think it's a losing proposition. From halmurray at sonic.net Mon Dec 18 17:34:25 2023 From: halmurray at sonic.net (Hal Murray) Date: Mon, 18 Dec 2023 09:34:25 -0800 Subject: Missing clockwork In-Reply-To: Message from James Browning via devel of "Mon, 18 Dec 2023 05:56:19 -0800." <1526166741.74531.1702907779236@privateemail.com> Message-ID: <20231218173425.EEDCB28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> James said: > It sounds like a race condition in our wscript files or waf. How willing are > you to sink time into this, I think it's a losing proposition. I've got a --jobs=1 in my script. That was added to make sure the printout was easy to read when there were compiler errors. I'm willing to invest some time on this but I don't have any ideas on what to do. Note that it was building 3 copies of clockwork [ 1/137] Compiling libntp/clockwork.c [ 2/137] Compiling libaes_siv/aes_siv.c [ 3/137] Compiling libntp/clockwork.c [ 4/137] Compiling libntp/clockwork.c I only expect 2 ./test-classic/main/libntp/clockwork.c.2.o ./test-doc/main/libntp/clockwork.c.1.o ./test-doc/main/libntp/clockwork.c.2.o ./libntp/clockwork.c -- These are my opinions. I hate spam. From Matthew.Selsky at twosigma.com Mon Dec 18 19:32:45 2023 From: Matthew.Selsky at twosigma.com (Matthew Selsky) Date: Mon, 18 Dec 2023 19:32:45 +0000 Subject: Release In-Reply-To: References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>

Message-ID: On Sun, Dec 17, 2023 at 08:17:23PM -0800, Fred Wright via devel wrote: Hi Fred, > The main issue I've found is that the "struct var" in ntp_control.c, is > relying on anonymous unions, which are a relatively new language feature. > They were originally a GNU extension, eventually becoming official in C11. > But significantly increasing the compiler requirements just for one table > doesn't seem terribly desirable. Should our use of "-std=c99" have caught this? Or is that flag not intended to catch features newer than standard X? > There are also a bunch of warnings with some compilers, which might be worth > looking at. They're often fairly easy to fix, and sometimes indicate actual > problems. Do you have specifics on distros/compilers that are showing warnings so we can run these to ground? > I also stumbled across something (which may not be new) where it appears > that if libaes_siv is installed as a system library, it's preferred over the > bundled version. That probably doesn't change the actual behavior, but may > lead to opportunistic builds. Interesting. Which distro includes libaes_siv as a system library? We don't modify libaes_siv so using the system version should be fine. Cheers, -Matt From fw at fwright.net Mon Dec 18 22:13:16 2023 From: fw at fwright.net (Fred Wright) Date: Mon, 18 Dec 2023 14:13:16 -0800 (PST) Subject: Release In-Reply-To: References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>

Message-ID: On Sun, 17 Dec 2023, Hal Murray wrote: > Fred Wright said: >> The main issue I've found is that the "struct var" in ntp_control.c, is >> relying on anonymous unions, which are a relatively new language feature. > > That is my attempt at getting a sane procedure for adding slots to the table. > The old scheme required coordinated edits in several places and there was no > checking that you got them right. I'm not objecting the the scheme - just the use of the newer C feature, which at first glance doesn't seem to add a lot of value here. >> Turning the "p_" and "p2_" prefixes into names of the union instances seems >> fairly reasonable (e.g., "p_time" becomes "p.time"), but would require >> changing the initializers. I'd be willing to look into that if I'm not >> wasting my time. > > I think I just fixed that. I'll push in a while after more local testing. I'll try it again once you've updated it. BTW, although names for the union types themselves aren't really needed in this context, it's sometimes useful to name them anyway for use by debuggers. Though I believe all union type names occupy a single namespace, which has to be considered when choosing names. >> There are also a bunch of warnings with some compilers, which might be worth >> looking at. They're often fairly easy to fix, and sometimes indicate actual >> problems. > > Which compilers? Or rather which OS/distros? > > Can we set things up so that the gitlab CI stuff tells us about warnings? > > James suggested adding the compiler flag that turns warnings into errors. > That won't work on the old old version of Bison that has a missing default or > something like that. That might be reasonable for CI testing, though it would be heavy-handed for the normal build procedure. Or even having CI tests both ways might be useful, to distiguish between errors and warnings. Though if CI tests had the ability to report error versus warning results, that would be unnecessary. On Mon, 18 Dec 2023, Matthew Selsky wrote: > On Sun, Dec 17, 2023 at 08:17:23PM -0800, Fred Wright via devel wrote: > > Hi Fred, > >> The main issue I've found is that the "struct var" in ntp_control.c, is >> relying on anonymous unions, which are a relatively new language feature. >> They were originally a GNU extension, eventually becoming official in C11. >> But significantly increasing the compiler requirements just for one table >> doesn't seem terribly desirable. > > Should our use of "-std=c99" have caught this? Or is that flag not intended to catch features newer than standard X? The latter. The "-std=c99" option by itself only guarantees *at least* C99. One needs to also include -pedantic to make it *at most* C99. If "-std=c99" is included unconditionally, that could also be a problem, since compilers that default to C99 might not support the option. Though if there's one of those "see if this option works" in the configure phase, that might take care of it. The ruby build procedure takes the more conservative approach of determining whether "-std=c99" is *needed* to get C99 features, rather than just testing whether the option is *recognized*. Though that test has a subtle bug that had me tearing my hair out for a while before finally noticing that the two messages that miscompared while being apparently identical were using different single-quote characters. :-) >> There are also a bunch of warnings with some compilers, which might be worth >> looking at. They're often fairly easy to fix, and sometimes indicate actual >> problems. > > Do you have specifics on distros/compilers that are showing warnings so we can run these to ground? For a first pass, it might be easier to just fix the issues than write them up. This mostly isn't about "distros". I have a whole bunch of different versions of gcc and clang on my primary Mac system, so testing against different compilers is fairly easy (given that it honors "CC="). I was able to run the build/test with 26 different compilers in about 7 minutes. There were another 5 in the match pattern that couldn't compile ntp_control.c due to the anonymous unions (gcc earlier than 4.9). For overall testing, I use a bunch of VMs with different Mac, Linux, and BSD installs. Although macOS earlier than 10.13 isn't officially supported, I maintain patches to make it work all the way back to 10.4 (which also happen to help OpenBSD). I only test with the patches where needed. >> I also stumbled across something (which may not be new) where it appears >> that if libaes_siv is installed as a system library, it's preferred over the >> bundled version. That probably doesn't change the actual behavior, but may >> lead to opportunistic builds. > > Interesting. Which distro includes libaes_siv as a system library? We > don't modify libaes_siv so using the system version should be fine. It's not a "distro". Back when libaes_siv was first mentioned, I assumed that it would be an external dependency and created a port for it in MacPorts. When ntpsec turned out to use its own bundled copy instead, I didn't add the libaes_siv port as a dependency, but it's still installed and maintained here. I don't know if anyone uses that port for other purposes, but it's installable on any Mac running 10.4 or later. On the Mac, the concept of "distros" is pretty meaningless, since very little is bundled by Apple, and what's actually installed is largely determined by what users have installed via MacPorts or Homebrew. Fred Wright From jamesb192 at jamesb192.com Mon Dec 18 22:52:48 2023 From: jamesb192 at jamesb192.com (James Browning) Date: Mon, 18 Dec 2023 14:52:48 -0800 (PST) Subject: Release In-Reply-To: <20231218054913.C2FDB28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: Message from Fred Wright via devel of "Sun, 17 Dec 2023 20:17:23 -0800." <20231218054913.C2FDB28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: <1193968159.114514.1702939968895@privateemail.com> > On 12/17/2023 9:49 PM PST Hal Murray via devel wrote: > > Fred Wright said: :::snip::: > > There are also a bunch of warnings with some compilers, which might be worth > > looking at. They're often fairly easy to fix, and sometimes indicate actual > > problems. > > Which compilers? Or rather which OS/distros? > > Can we set things up so that the gitlab CI stuff tells us about warnings? > > James suggested adding the compiler flag that turns warnings into errors. > That won't work on the old old version of Bison that has a missing default or > something like that. I also would be interested in seeing these errors for myself. there is also 'clang -Weverything' and some weblinks - https://gitlab.com/NTPsec/ntpsec/-/security/vulnerability_report - https://app.codacy.com/gl/NTPsec/ntpsec/dashboard - https://scan8.scan.coverity.com/#/project-view/50864/11242 I am also attaching a file derived from the output of clang. A previous attempt to send a more complete listing had issues. -------------- next part -------------- -Weverything (x86_64 Linux Clang 16) 1889 -Wunsafe-buffer-usage 1382 -Wpadded 375 -Wextra-semi-stmt 167 -Wdouble-promotion 103 -Wsign-conversion 81 -Wshorten-64-to-32 65 -Wimplicit-int-conversion 58 -Wmissing-variable-declarations 56 -Wdeclaration-after-statement 53 -Wunused-macros 52 -Wimplicit-int-float-conversion 32 -Wcovered-switch-default 23 -Wimplicit-float-conversion 20 -Wdisabled-macro-expansion 17 -Wformat-nonliteral 16 -Wunreachable-code-break 14 -Wunreachable-code 12 -Wfloat-conversion 10 -Wcast-align 8 -Wimplicit-fallthrough 5 -Wcast-function-type-strict 5 -Wbad-function-cast 4 -Wused-but-marked-unused 4 -Wreserved-identifier 2 -Wextra-semi 2 -Wconditional-uninitialized 2 -Wcomma 1 -Wunreachable-code-return 1 -Wstring-conversion 1 -Wreserved-macro-identifier -Weverything (arm64 macOS clang 15) 1310 -Wpadded 404 -Wunused-macros 158 -Wpoison-system-directories 99 -Wsign-conversion 82 -Wshorten-64-to-32 57 -Wmissing-variable-declarations 54 -Wdeclaration-after-statement 52 -Wimplicit-int-conversion 28 -Wcovered-switch-default 22 -Wcast-align 17 -Wformat-nonliteral 16 -Wunreachable-code 13 -Wunreachable-code-break 8 -Wimplicit-float-conversion 6 -Wdouble-promotion 5 -Wbad-function-cast 4 -Wused-but-marked-unused 3 -Wfloat-conversion 2 -Wextra-semi 2 -Wdisabled-macro-expansion 2 -Wconditional-uninitialized 1 -Wunreachable-code-return 1 -Wstring-conversion From fw at fwright.net Thu Dec 21 09:15:25 2023 From: fw at fwright.net (Fred Wright) Date: Thu, 21 Dec 2023 01:15:25 -0800 (PST) Subject: Release In-Reply-To: References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net>

Message-ID: On Mon, 18 Dec 2023, Fred Wright wrote: > On Mon, 18 Dec 2023, Matthew Selsky wrote: >> On Sun, Dec 17, 2023 at 08:17:23PM -0800, Fred Wright via devel wrote: >> >>> There are also a bunch of warnings with some compilers, which might be >>> worth >>> looking at. They're often fairly easy to fix, and sometimes indicate >>> actual >>> problems. >> >> Do you have specifics on distros/compilers that are showing warnings so we >> can run these to ground? > > For a first pass, it might be easier to just fix the issues than write them > up. I just created MR !1361, which fixes all warnings with the 28 compilers I tested with. I'll do some multiplatform testing tomorrow, though I don't expect any downside to those chages. Fred Wright From fw at fwright.net Thu Dec 21 09:34:11 2023 From: fw at fwright.net (Fred Wright) Date: Thu, 21 Dec 2023 01:34:11 -0800 (PST) Subject: Missing clockwork In-Reply-To: <20231218173425.EEDCB28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231218173425.EEDCB28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: On Mon, 18 Dec 2023, Hal Murray via devel wrote: > James said: >> It sounds like a race condition in our wscript files or waf. How willing are >> you to sink time into this, I think it's a losing proposition. > > I've got a --jobs=1 in my script. That was added to make sure the printout > was easy to read when there were compiler errors. It's usually best not to do that unconditionally, since it makes things a lot slower. Better to use the usual parallelism initially, then repeat with "-j1" if it's determined to be needed. For example, here the parallel build from "git clean -dxf" takes ~12.1 seconds, while -j1 makes it take ~47.7 seconds. Note that -j1 doesn't guarantee correctness; it only guarantees consistency. The typical issue with problems of this form is missing dependencies. With -j1 there's a consistent build order, which may or may not be accidentally correct if dependencies are missing. With the default parallel builds, the build order becomes variable, but should still respect declared dependencies. If you build with -j1 and -v, you may be able to see what's expecting clockwork to exist without depending on it. It's possible to use pdb in waf if you're sufficiently masochistic. :-) Fred Wright From fw at fwright.net Fri Dec 22 05:39:28 2023 From: fw at fwright.net (Fred Wright) Date: Thu, 21 Dec 2023 21:39:28 -0800 (PST) Subject: Regression in OpenBSD Message-ID: <0a8a6333-f477-6d66-29ba-8be2f106e52d@fwright.net> I found one build error that's a regression - in OpenBSD 5.6. It's "'CMAC_CTX' undeclared" in authreadkeys.c, which is due to the new conditional around the inclusion of . Some other sources include this unconditionally, and macencrypt.c has it in an if/else construct. The else case there would be implicitly <= 0x20000000L, while the condition here is < 0x20000000L. That seemed like a hint, so I tried changing the "<" to "<=" (line 26 of authreadkeys.c), and that fixed it. That suggests that other cases of "< 0x20000000L" may incorrect as well. Perhaps this OpenBSD install is the only case where the value of OPENSSL_VERSION_NUMBER == 0x20000000L. Ntpsec doesn't fully support OpenBSD anyway, due to the lack of "timex" (though my Mac patches fix that), and the fact that OpenBSD provides LibreSSL rather than OpenSSL, but the 1.2.2a "Mac" version did build with --disable-nts. NetBSD 6.1.5 also fails due to a missing declaration for ldexpl, but that's not a new problem. Fred Wright From fw at fwright.net Fri Dec 22 05:47:43 2023 From: fw at fwright.net (Fred Wright) Date: Thu, 21 Dec 2023 21:47:43 -0800 (PST) Subject: Regression in OpenBSD In-Reply-To: <0a8a6333-f477-6d66-29ba-8be2f106e52d@fwright.net> References: <0a8a6333-f477-6d66-29ba-8be2f106e52d@fwright.net> Message-ID: On Thu, 21 Dec 2023, Fred Wright via devel wrote: > I found one build error that's a regression - in OpenBSD 5.6. It's > "'CMAC_CTX' undeclared" in authreadkeys.c, which is due to the new > conditional around the inclusion of . Some other sources > include this unconditionally, and macencrypt.c has it in an if/else > construct. The else case there would be implicitly <= 0x20000000L, while the > condition here is < 0x20000000L. That seemed like a hint, so I tried > changing the "<" to "<=" (line 26 of authreadkeys.c), and that fixed it. That > suggests that other cases of "< 0x20000000L" may incorrect as well. Perhaps > this OpenBSD install is the only case where the value of > OPENSSL_VERSION_NUMBER == 0x20000000L. I forgot to mention that fixing this turned up a couple of additional warnings: [ 58/121] Compiling ntpd/ntp_control.c ../../ntpd/ntp_control.c: In function 'process_control': ../../ntpd/ntp_control.c:794: warning: ignoring alignment for stack allocated 'pkt_core' ../../ntpd/ntp_control.c: In function 'read_ordlist': ../../ntpd/ntp_control.c:3545: warning: ignoring alignment for stack allocated 'pkt_core' [101/121] Compiling build/host/ntpd/ntp_parser.tab.c ntp_parser.tab.c:555:6: warning: "YYENABLE_NLS" is not defined ntp_parser.tab.c:1481:6: warning: "YYLTYPE_IS_TRIVIAL" is not defined And a couple that are typical OpenBSD pedantry: [103/121] Linking build/main/ntpd/ntpd ntpd/ntp_packetstamp.c.17.o(.text+0x11a): In function `fetch_packetstamp': ../../ntpd/ntp_packetstamp.c:178: warning: random() isn't random; consider using arc4random() [147/237] Linking build/main/tests/test_libntp tests/libntp/ntp_random.c.2.o(.text+0x1f4): In function `TEST_random_random32_': ../../tests/libntp/ntp_random.c:27: warning: random() isn't random; consider using arc4random() > Ntpsec doesn't fully support OpenBSD anyway, due to the lack of "timex" > (though my Mac patches fix that), and the fact that OpenBSD provides LibreSSL > rather than OpenSSL, but the 1.2.2a "Mac" version did build with > --disable-nts. > > NetBSD 6.1.5 also fails due to a missing declaration for ldexpl, but that's > not a new problem. Fred Wright From halmurray at sonic.net Fri Dec 22 06:25:14 2023 From: halmurray at sonic.net (Hal Murray) Date: Thu, 21 Dec 2023 22:25:14 -0800 Subject: Regression in OpenBSD In-Reply-To: Message from Fred Wright via devel of "Thu, 21 Dec 2023 21:39:28 -0800." <0a8a6333-f477-6d66-29ba-8be2f106e52d@fwright.net> Message-ID: <20231222062514.9CDF128C20C@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Let's put that stuff on the back burner until the release is out. > Ntpsec doesn't fully support OpenBSD anyway, due to the lack of "timex" > (though my Mac patches fix that), and the fact that OpenBSD provides > LibreSSL rather than OpenSSL, but the 1.2.2a "Mac" version did build with > --disable-nts. Please say more about your Mac patches? Does ntpd work? -- These are my opinions. I hate spam. From fw at fwright.net Sat Dec 23 03:02:12 2023 From: fw at fwright.net (Fred Wright) Date: Fri, 22 Dec 2023 19:02:12 -0800 (PST) Subject: Regression in OpenBSD In-Reply-To: <20231222062514.9CDF128C20C@107-137-68-211.lightspeed.sntcca.sbcglobal.net> References: <20231222062514.9CDF128C20C@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: On Thu, 21 Dec 2023, Hal Murray wrote: > Let's put that stuff on the back burner until the release is out. Agreed for OpenBSD per se, though it might be worth trying to determine whether the apparent fencepost error with OPENSSL_VERSION_NUMBER is really OpenBSD-specific, or a more general problem that happens to show up here only in OpenBSD. All the conditionals for it seem to be either '<' or '>', leaving the '==' case to fall through a crack. Unless the intent is actually tri-valued behavior, one or the other should include the '==' case. Admittedly, it's weird that the '==' case seems to want to be included in the '<' case rather than the '>' case. I'll probably look into the additional warnings at some point, but not worry about it until after the release. >> Ntpsec doesn't fully support OpenBSD anyway, due to the lack of "timex" >> (though my Mac patches fix that), and the fact that OpenBSD provides >> LibreSSL rather than OpenSSL, but the 1.2.2a "Mac" version did build with >> --disable-nts. > > Please say more about your Mac patches? The patches come in two categories: Fallback for missing clock_gettime() and clock_settime(). This is fairly straightforwardly implemented as inlines in ntp_machine.h. Then some miscellaneous programs that use clock_gettime() and don't include ntp_machine.h need to be fixed to do so. Allowing the "timex" stuff to be optional, as it once was. Originally I just reverted the two commits that caused the problem, but then subsequently have had to fix conflicts with other changes from time to time. It could probably be refactored to better localize the relevant stuff, but fixing the conflicts is always incrementally easier. The first category would probably be acceptable for inclusion in mainline, but by itself it doesn't expand the compatibility range. The second category as it is would probably be too much code clutter. > Does ntpd work? Yes, it works, except in one weird case that I haven't taken the time to investigate. In 10.5 x86_64, it builds and passes the tests, but looking with "ntpq -p", it shows all the initial peers but no actual exchanges happening. 10.5 ppc and 10.5 i386 work fine, as do all the other cases I can test. If I ever get around to fixing that, it will probably suggest some deficiency in the tests that's probably worth fixing. Fred Wright From halmurray at sonic.net Sat Dec 23 06:43:06 2023 From: halmurray at sonic.net (Hal Murray) Date: Fri, 22 Dec 2023 22:43:06 -0800 Subject: Regression in OpenBSD In-Reply-To: Message from Fred Wright of "Fri, 22 Dec 2023 19:02:12 -0800." Message-ID: <20231223064306.7860928C20C@107-137-68-211.lightspeed.sntcca.sbcglobal.net> >> Please say more about your Mac patches? > The patches come in two categories: > Fallback for missing clock_gettime() and clock_settime(). My copy of OpenBSD 7.4 has clock_gettime() and clock_settime(). So we can take the first step without changing that area. The timex stuff will be a bit more complicated. They have something to set the drift. I forget what it is called. What ntp_adjtime() does is kick the drift by 500 PPM for as long as it takes to make the target adjustment. We can fake that. It won't be as good as as doing it in the kernel. It will be fun to measure. -- These are my opinions. I hate spam. From fw at fwright.net Mon Dec 25 22:51:59 2023 From: fw at fwright.net (Fred Wright) Date: Mon, 25 Dec 2023 14:51:59 -0800 (PST) Subject: Bug in Attic Build Message-ID: <580092b2-51a7-b8cd-3dec-9781ac0949ce@fwright.net> Commit 07231d10e2 to add cipher-find also added exp-timing.c to the build list but didn't actually add a source for it. Thus the attic build fails. It probably makes sense to fix this before the release since it's a regression and also doesn't affect any normally installed components, and hence doesn't affect pre-release testing. Fred Wright From fw at fwright.net Tue Dec 26 22:27:27 2023 From: fw at fwright.net (Fred Wright) Date: Tue, 26 Dec 2023 14:27:27 -0800 (PST) Subject: Bug in Attic Build In-Reply-To: <580092b2-51a7-b8cd-3dec-9781ac0949ce@fwright.net> References: <580092b2-51a7-b8cd-3dec-9781ac0949ce@fwright.net> Message-ID: <4a78606f-e5e2-5cb3-5774-7ced6c5713b2@fwright.net> On Mon, 25 Dec 2023, Fred Wright via devel wrote: > Commit 07231d10e2 to add cipher-find also added exp-timing.c to the build > list but didn't actually add a source for it. Thus the attic build fails. > > It probably makes sense to fix this before the release since it's a > regression and also doesn't affect any normally installed components, and > hence doesn't affect pre-release testing. I just submitted MR !1367 to remove the offending reference. If the intent is to add an "exp-timing" program, that can be done later. Fred Wright From Matthew.Selsky at twosigma.com Fri Dec 29 05:18:43 2023 From: Matthew.Selsky at twosigma.com (Matthew Selsky) Date: Fri, 29 Dec 2023 05:18:43 +0000 Subject: Release In-Reply-To: References: <20231203040900.1F85E28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Message-ID: On Wed, Dec 06, 2023 at 01:56:51AM +0000, Matthew Selsky via devel wrote: > Sounds good. I'll aim to release ~15-Dec-2023. Hi all, Sorry for the delays. I have a release candidate tarball available: https://ftp.ntpsec.org/pub/releases/ntpsec-1.2.3rc1.tar.gz https://ftp.ntpsec.org/pub/releases/ntpsec-1.2.3rc1.tar.gz.asc I'll wait until late Saturday and then publish a final tarball. Thanks, -Matt From halmurray at sonic.net Sun Dec 31 07:52:34 2023 From: halmurray at sonic.net (Hal Murray) Date: Sat, 30 Dec 2023 23:52:34 -0800 Subject: NTPsec 1.2.3 released In-Reply-To: Your message of "Sun, 31 Dec 2023 06:50:59 +0000." Message-ID: <20231231075235.01F5D28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> Thanks. and thanks to all who contributed and tested. -- These are my opinions. I hate spam.