> On 08/22/2023 3:29 AM PDT Hal Murray <halmur...@sonic.net> wrote: > > > James Browning said: > > If the project is sleeping, then you may as > > well cut the new release now. > > I think we should do a normal release. That includes scanning the issues and > merge requests. And lots of testing. > > I'm working on making a couple of new stats files for NTP packets using NTS > and NTS-KE. That should enable fixing #795 (ntpviz) and provide data for > thinking about #797 (TLS server priority bit). > > I think we should fix the mssntp hack or decide to rip it out.
Some people will accuse us of throwing away perfectly good code either way. I am getting bogged down in the weeds working on an asynchronous implementation of the MS-SNTP shim. > > I would > > appreciate it if people commented on my merge > > requests 1331, 1333, and 1335. > > 1335: > sysstats are not resetting hourly when not logged to a file > ntp.poly.polychr() is broken on Python 2 (incorrectly reported as Python > 3 > on the ML) > ./waf requires Python development headers when building no ntp.ntpc or > Python w/ FFI ntp.ntpc > Minor text fixups in many Python files > 9 tests/libntp/*y do not have pyshebang headers > 6 test files, two wscript files, and ntp.agentx all lack SPDX > licenses > declarations > 9 pylib files and 8 test files lack license attribution > wscript files in tests and pylib lack UTF-8 coding lines > > That looks like 4 unrelated things in one MR. There is only one "approve" > button. > I'm interested in the first one, but not interested enough to try to dig it > out from all the other stuff. I can and will drop the other commits quickly enough. > 1333: > 2403ed08 - 1 commit from branch NTPsec:master > 18336fa1 - ms-sntp: works up to trying to connect to the socket. > 5535c882 - ms-sntp: Add excessive logging. > > Do we have a test setup yet? There was a lot of discussion a few weeks ago, > but I don't remember seeing a recipe for one. I have one that seems to need fixing. It keeps returning 4+12 octet messages that Samba wouldn't/couldn't sign the return message. > Again, There is only one "approve" button and I'm not going to approve > anything that says "excessive logging". > > If you need more info for debugging... There are several approaches. > > 1) Use the normal msyslog, but make sure it doesn't turn into a self-DoS. > You can add some rate limiting. I am using msyslog, but I did not add rate limiting. It logs once per packet failure condition, and it is single elimination. I need to look at rete limiting. > 2) You can use the DEBUG stuff. I've never been happy with that -- too much > other printout to wade through. > > 3) You can add the msyslog stuff with an ifdef or if (0) that defaults to > off. You edit the file and rebuild to turn on your extra printout. This > seems to work well if you are likely to want the same printout in the future. > You change a (0) to (1) rather than typing in the whole long line again. > > > 1331: > ntpdig appends a new mac after each host dug > ntpdig can try to take the trusted attribute of a byte string. > the authenticator bits in ntp.packet do not truncate digests > > I can't quite figure out what that means. Does it print something stupid? > Crash? > How would I test it? The first commit addresses running authenticated ntpdig against a hostname with multiple addresses adds an authenticator before getting time from each IP. So the second address gets two, the third three, and so on, causing ntpd to drop them as invalid. The second commit addresses coding errors in ntpdig. It tries to get access to two attributes from a string (think uint8_t[]) the neither has nor can have them. for the third commit if ntpq/ntpdig authenticates with a long hash (possibly sha2/sha3/blake) the authenticator is not truncated at 4+20 bytes causing ntpd to drop the packet as invalid. > My head doesn't like python. I'd be happier if somebody else tested/approved > this. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
