“same as NTP” is hard since it’s a complex software
goal:
We want to use sdwdate since that is safer (and working) over Tor.
A remote server being connected to (over Tor of course) might see the local VM clock through local clock leaks. And see it being adjusted. Ideally it would look to the server like:
Could be a normal (Debian or so) host system running Tor.
Running the currently most popular time synchronization software. (NTP?)
Currently being its time adjusted using that popular time sync software.
Not knowing it’s actually sdwdate / slow clock adjuster.
discussion:
The old goal was “make the time adjustments looking the same as NTP while actually using sdwdate”. Since Debian apparently switched to systemd-timesyncd by default (?), and since “same as NTP” is hard, what about switching the goal to “same as systemd-timesyncd”?
Another option worth exploring is chrony - because it already
(somewhat?) accepts external sources through an interface. I.e. we might
be able to disable chrony’s own networking and time fetching. Feed
chrony with sdwdate. Then use chrony’s slow clock adjusting.
systemd-timesyncd seems default on Debian, but it is not on CentOS. That doesn’t mean we couldn’t mimic its behaviour (or that of cronky or ntpd) but if we do we should make sure that the results are only used (if at all) after the clock has been set in a safe way, which is the first thing to solve.
Given that the alternatives to systemd-timesyncd are probably more stand-alone it might be more difficult to fake systemd-timesyncd behaviour than the behaviour of other tools.
A sclockadj3 should IMO be based on the simplest alternative from ntpd/cronky/systemd-timesyncd/other code that can actually run without doing unsafe NTP protocol based time queries (or if they are done, discard them, or only use them as a check, not as a source). Simplest in the sense of lines of code, because that leads to the smallest package to maintain, iff we have to make changes at all. E.g. chrony (at 32KLOC about a tenth of ntpd), claims that it can run from manual input. In case manual input always makes the clock jump we could probably emulate a GPS receiver without PPS (through gpsd, but then gpsd source is about 52KLOC)
Going that route, instead of reimplementing the interaction with the kernel as tried in slockadj2 is AFAIKT now much simpler.
Okay. Let’s go for a non-perfect solution that can be done and that is maintainable.
If we can emulate/interface with systemd-timesyncd code’s, awesome. If it seems not maintainable, never mind. Or we use ntpd as our second best choice. If that does not work either… Interfacing with chrony, if that works, that is good also. Everything is better than what we have right now.