Right. Yes. Maybe I am also confused. With that post I wanted to explain why it was a plugin and whatnot. And failed to express that.
If we wanted to go for ideal upstream inclusion chances and separation, the ideal way would be to come up with a plugin infrastructure. But that seems needlessly difficult to me.
I guess it’s best to add it to sdwdate-daemon. If available, use it. Otherwise, silently skip it. [Unless more verbose.]
Timesanitycheck is something worthwhile to run before the first fetch as well as after setting the time. But wait… Why after setting the time? Let’s rethink…
Why check bootclockrandomization at all? While reimplementing this, we just copied the previous implementation. Not a great reason. That package bootclockrandomization is working pretty well for a long time now. Seeing it broken is unlikely. If we wanted, we could check bootclockrandomization in whonixcheck. Finding out if it was ever broken could be part of the usual Whonix development / testing work.
And as for timesanitycheck, actually that’s a pretty simple action. See:
https://github.com/Whonix/timesanitycheck/blob/master/usr/share/timesanitycheck/start
Summary:
- After start: Gets a timestamp. It gets the current unixtime for use in script calculation and human readable date/time for pretty output.
- Reads a few more existing time stamps. Build timestamp.
- And expiration timestamp.
- Then compares.
- if BOOT_UNIXTIME is lower than BUILD_UNIXTIME → pretty your clock is fast log output
- if BOOT_UNIXTIME is greater than EXPIRATION_UNIXTIME → pretty your clock is slow log output
- creates status files as appropriate but that is not so important
I am wondering if the whole thing should be reimplemented in python? Or if I should just deprecate the package and make the scripts easily accessible from python? A timesanitycheck does have nothing to do with anonymity. Is useful.
If the clock is slow before fetching for the first time, and most likely therefore cannot be set, it’s a helpful information to fix the issue. And before setting the new timestamp it’s also useful to check if it’s within a sane range, that is between BUILD_UNIXTIME and EXPIRATION_UNIXTIME. Otherwise, drop the fetched time result as invalid.
I hope that makes a lot more sense?
(There is another sanity check, “sdwdate Tor Consensus Time Sanity Check” - ⚓ T151 sdwdate Tor Consensus Time Sanity Check, that can be added at a later time after the first release. Building such a sanity check into sdwdate is also independent from anonymity stuff, because sdwdate now depends on Tor anyhow. So why not use also Tor as a source for sanity checking. From that perspective, an external timesanitycheck package makes less sense.)