ntpd-rs: update to 1.9.0

[slymattz]

Testing the changes

• I tested the changes in this PR: YES

$ doas sv restart ntpd-rs
[waiting a few minutes for it to fully sync]
$ ntp-ctl status                                
Synchronization status:
        Dispersion:     0.000129s
        Delay:          0.008670s
        Stratum:        4


Sources:

ntpd-rs.pool.ntp.org:123 46.175.224.7:123 (1)
        Offset:                 -0.000954
        Uncertainty:            ±0.000083
        Delay:                  ±0.012180
        Poll interval:          16s
        Missing polls:          0
        Root dispersion:        0.026428s
        Root delay:             0.007431s

Local build testing

• I built this PR locally for my native architecture: x86_64-glibc
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • aarch64-musl (crossbuild)

[ihameed]

@slymattz, do you remember why you partially patched this to use ring instead of aws-lc-rs? This makes ntpd-rs panic, when NTS is used, with a message like this:

thread 'main' (870) panicked at /host/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustls-0.23.40/src/crypto/mod.rs:249:14:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.
See the documentation of the CryptoProvider type for more information.

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

A patch that removes aws-lc-rs from the cargo dependency graph and fully replaces it with ring looks like this: https://gist.github.com/ihameed/5deaeeb096d782dc5608472311529f04

Otherwise, CryptoProvider::from_crate_features will see the cfg flags aws-lc-rs when compiled and the resulting implementation of that function will refuse to provide a default.

An NTS example in ntp.toml:

[[source]]
mode = "nts"
address = "time.cloudflare.com"

I've submitted a PR to undo the ring change, but I personally don't care much if this uses aws-lc-rs (it's annoying to build on windows b/c of nasm) or ring.

[slymattz]

@ihameed Hi! Thanks for the report. To be honest, I can’t reproduce this locally with:

[[source]]
mode = "nts"
address = "time.cloudflare.com"

ntpd-rs starts without panicking on my machine. ntp-ctl status runs fine, too.

That said, if dropping the patch fixes the issue for you, then that’s probably the safer approach. You could probably also drop the post_patch() bit, since it was only there to refresh the lockfile after patching Cargo.toml.

[ihameed]

@ihameed Hi! Thanks for the report. To be honest, I can’t reproduce this locally with:

[[source]]
mode = "nts"
address = "time.cloudflare.com"

ntpd-rs starts without panicking on my machine. ntp-ctl status runs fine, too.

That said, if dropping the patch fixes the issue for you, then that’s probably the safer approach. You could probably also drop the post_patch() bit, since it was only there to refresh the lockfile after patching Cargo.toml.

Weird! I see that panic on startup on both arm64 and x86-64 with ntpd-rs-1.9.0_1 from the void binary package repo, or with ntpd-rs built by hand from a copy of the upstream repository with the patch applied. And after looking at the source to rustls, it looks like this panic ought to always happen given that both the "aws-lc-rs" and "ring" --cfg flags are enabled via cargo with the patch from this PR. My full ntp.toml:

[observability]
# Other values include trace, debug, warn and error
log-level = "warn"
observation-path = "/var/run/ntpd-rs/observe"
observation-permissions = 0o660
ansi-colors = false

# Pool servers from ntppool.org. See http://www.pool.ntp.org/join.html
# for more information
[[source]]
mode = "pool"
address = "ntpd-rs.pool.ntp.org"
count = 4

[[source]]
mode = "nts"
address = "time.cloudflare.com"

# Alternative configuration for IPv6 only machines
#[[source]]
#mode = "pool"
#address = "2.pool.ntp.org"
#count = 4

# Below are configured various thresholds beyond which ntpd-rs will not
# change the system clock. CHANGE THESE TO MATCH YOUR SECURITY NEEDS!
# For guidance, see OPERATIONAL_CONSIDERATIONS.md
[synchronization]
single-step-panic-threshold = 1800
startup-step-panic-threshold = { forward="inf", backward = 1800 }
#accumulated-step-panic-threshold = 1800
#minimum-agreeing-sources = 3