Release, project sleeping, and running down the clock.

James Browning jamesb192 at jamesb192.com
Tue Aug 22 13:09:55 UTC 2023


> On 08/22/2023 3:29 AM PDT Hal Murray <halmurray at 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.


More information about the devel mailing list