Re: Regression in OpenBSD
>> 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. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Regression in OpenBSD
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 ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Regression in OpenBSD
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. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Regression in OpenBSD
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 <= 0x2000L, while the condition here is < 0x2000L. 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 "< 0x2000L" may incorrect as well. Perhaps this OpenBSD install is the only case where the value of OPENSSL_VERSION_NUMBER == 0x2000L. 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 ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Regression in OpenBSD
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 <= 0x2000L, while the condition here is < 0x2000L. 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 "< 0x2000L" may incorrect as well. Perhaps this OpenBSD install is the only case where the value of OPENSSL_VERSION_NUMBER == 0x2000L. 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 ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
