Re: What next?

2024-03-18 Thread Hal Murray via devel


James Browning said:
>> 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 can take small steps.  Or at least some of them.


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

It wasn't the NTP WG -- they had a draft RFC ready to go.  The group that 
vetoed it was the group in charge of rationing port assignments.



[testing config file]
> 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. 

Internally, there is a parse tree.  But it doesn't contain the comments.

I'm not interested in that, but if you want to work on it, it might be a 
useful utility.


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

There is a HOWTO-OpenSSL that tells you how to build OpenSSL from source.  
Adding enable-fips to the configure step builds/tests/installs the FIPS 
library too.

The recent FIPS discussion has a recipe for getting libssl to use it.  I 
haven't tried that step yet.


>> I'd like a script that checks the certificates.  When do they expire?
> That sounds like a simple wrapper around 'openssl x509' would work. 

I think it will be something simple like that after we do it.  I've poked 
around a few times but never ended up with anything clean.  The openssl 
command has a blizzard of options.

This just got more important for me.  I fatfingered renewing a certificate and 
a KE server stopped working.  [I did the certbot step but forgot to copy the 
new cert/key over to /etc/ntp/.]


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel


Re: What next?

2024-03-18 Thread James Browning via devel
On 03/17/2024 at 2:00 PM PDT, Hal Murray via devel  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.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel