What next?

James Browning jamesb192 at jamesb192.com
Mon Mar 18 11:14:07 UTC 2024


On 03/17/2024 at 2:00 PM PDT, Hal Murray via devel <devel at ntpsec.org> wrote:
> 
> Is anybody thinking about what we should be doing?
> 
> 
> Here is my list:
> 
> Port to Windows
> Does anybody know anything about Windows?
> Is there a decent POSIX environment?
> How well does waf work on Windows?
> We can get the magic code from ntp-classic.

I have forgotten almost everything about MS Windows. It claims to
have a POSIX environment, but it is not.

IIRC waf works on MS Windows; our main configuration does not so
much.

The portability shim should still be available at the
git-conversion tag, fitting it in will be annoying.

> I think we should split ntpd into several independant programs.
> More in another message.

I gave up on that notion; I lacked the patience to do it.

> I think we need a good SNTP client. Something like the old ntpdate.
> I'm looking for a clean example.
> This would be a good opportunity to experiment with Go and/or Rust.
> 
> Getting off the ground.
> There is a chicken-egg problem with getting started when using NTS. TLS
> needs the time to check certificates. I think we can do something like skip
> the date part of certificate checking, then come back and see if the
> certificates pass the date-check after we have a candidate date.

Dusting all the corners would be irritating.

> Alternate port for use with NTS.
> There is a lot of blocking/filtering on port 123. NTS-KE includes
> specifying the port to use. We should be able to listen on another port too.
> I haven't looked carefully. This feels like medium complexity.

Yeah, the IETF NTP WG shot down the notion of NTP alternative port.

...

> We should test the config file stuff to see that all the options at least get 
> past the parser.  Better would be to actually run the code.

I think somewhere in the middle might be a program that takes config
files and dumps them into some format that is easy to eyeball and
machine parse.

> We should check FIPS mode.  Do any of the CI options include FIPS?
> I got half way there by building OpenSSL to include FIPS mode but I haven't 
> made the config file to use it.

None of the CI runners support FIPS140-2 at the moment.
I don't know how to make them either.

> I'd like a script that checks the certificates.  When do they expire?

That sounds like a simple wrapper around 'openssl x509' would work. 

If OpenSSL does not work, you are probably looking at something much
heavier in the front.

> I'd like a script that finds out who signed a certificate and pokes around in 
> my local certificate collection and tells me a filename so I can add that to a 
> server line in the config file.  The idea is to make sure that we are using 
> the right root-cert rather than one from a CA that was arm twisted by your 
> local repressive govt or broken into by the KBG or NSA.

Perhaps we could call it cert-sweep and also dump the hash, notAfter
and other data from the certificates to standard out as well.


More information about the devel mailing list