sdwdate and sdwdate-gui development thread

Since the name of the branch is ‘python’, there is no need for hesitation to delete the bash stuff. Once the ‘python’ branch is ready, we just merge it into ‘master’. For the time being, there are no conflicts to avoid.

Pushed some commits in GitHub - troubadoour/sdwdate at python.

The IO errors are handled in sdwdate class. I the case of Whonix Forum, if all the remotes are down in a pool, can we accept to use only too pools, with the proper warnings?

A logic flaw corrected.

if all the remotes are down in a pool, can we accept to use only too pools, with the proper warnings?
I think this situation would be super fishy. All members of one pool down. Should be careful then and not continue.

[hr]

Please restore the postinst / postrm script. We still need it for setup of sclockadj.

More review to come.

Also please restore sclockadj.

Not sure if sclockadj_debug_helper should be restored. Sclockadj issues were fixed out. Probably no more debugging required.

sclockadj_kill_helper will still be required, unless you want to replace it by a python script. Rewrite probably not required since that script was working flawless.

Also please restore usr/lib/tmpfiles.d/sdwdate.conf - still required for systemd / folder creation at startup.

Wil (try to) restore sclockadj. For the moment, parsing /etc/sdwdate.d/30_sdwdate_default.

If I undesrstand “sdwdate_pick_single_link_from_maybe_multi_lined_mirror_list()”, if a multi-line entry exists in a pool, we use it by default.

That’s what is done in the last two commits, reverting to the single line list if none exists.

Not parsing link_port yet. By the way, is there any chance that we’ll use another port than 80?

If I undesrstand "sdwdate_pick_single_link_from_maybe_multi_lined_mirror_list()", if a multi-line entry exists in a pool, we use it by default.
- At iteration time (at every fetch)... - Not at config load time. - If and only if we happened to randomly choose a multi lined pool member from a pool, then we pick a random mirror of that pool member.

Multi lined pool members are only used as 1 entity. For trust reasons. That means, just because someone provides 10 mirrors, that pool member is not used 10 times more than a single lined pool member.

By the ability to provide mirrors to pool members, we give them a way to provide load balancing. They won’t be used more often.

Not parsing link_port yet. By the way, is there any chance that we'll use another port than 80?
Yes, there is one from riseup already in the list which uses 443.
- If and only if we happened to randomly choose a multi lined pool member from a pool, then we pick a random mirror of that pool member.

The logic:

  • config.py creates multi-line and single-line sub pools.
  • Swdate init checks if a multi-line entry exists in the pool. If yes, increments the range of the RNG.
  • in sdwdate_loop, if the the index or the member to pick is outside the range of the single-line pool, select the multi-line and pick a random member from it.

Limitation: at the moment, the script is able to manage only one multi-line per pool.

If it would help, we could also change the pool syntax. Make all pool members “multi lined”. Using same syntax. Just “single line” multi lined.

Some commits.

Continuing with random nanoseconds add / substract, set time using date. From there, I will need some clarifications about the options that are actually used in sdwdate. From what I can gather:

  • startup (at boot or from timesync) → set time using date.
  • restartup after sdwdate sleep period → set time using date.
  • user restartup → set time using sclockadj.

Ah. Yes. While we’re at it, maybe those set by date vs sclockadj situations also need some scrutiny/rethinking.

After boot → set time using date. Rationale: after boot the time could be very wrong.

After sleep period → set time using sclockadj. Rationale: prevent clock jumps in running system.

Restart by system (apt-get upgrade), i.e. if the first success file already exists → set time using sclockadj. Rationale: prevent clock jumps in running system.

Restart by user using timesync → timesync runs the restart_fresh script. It deletes the first success file. → set time using date. Rationale: manual run by a user who is unhappy with current time and/or wants to unlink and/or wants a bigger change.

- Create a separate etc/sdwdate-python.d/30_sdwdate_default configuration file. Modifying the original crashes sdwdate bash (expected).
Let's please just keep /etc/sdwdate.d. Incompatibility with sdwdate-bash is fine. sdwdate-bash will be deprecated. Transition (Whonix 11 sdwdate-bash -> Whonix 12 sdwdate-python) will most likely be smoothly. The package management stops sdwdate-bash, replaces the configuration file and starts sdwdate-python. Changing the folder would generate extra work, require to also update the sdwdate plugins as well as qubes-whonix package.

This is a temporary solution. If I modify directly the existing default file, sdwdate bash does not work. As sdwdate-python package progresses, it should be easy to revert to the original /etc/sdwdate/ 30_sdwdate_default.

Okay. Nevermind. But do we need those co-installed for development purposes? Anyhow. Minor detail. Nevermind.

Ah. Yes. While we're at it, maybe those set by date vs sclockadj situations also need some scrutiny/rethinking.
Plunging into sneaky clock adjust. I'm probably missing something, but a remark nonetheless.

sclockadj is running more or less permanently in the background. Every second [SDWDATE_SCLOCKADJ_WAIT_MIN = $SDWDATE_SCLOCKADJ_WAIT_MAX], it add /subtract 500 microsecond [SDWDATE_SCLOCKADJ_MOVE_MIN = SDWDATE_SCLOCKADJ_MOVE_MIN] to the clock, that is 1.8 second per hour. No problem there. But, does that mean that all Whonix users share the same clock drift when sclockadj is running? That might be an advantage In case of clock skew fingerprinting, as the skew cannot be pinned to an individual user, but it seems that an attacker could easily tie it to Whonix.

With sclockadj, it’s “same as NTP”. Hopefully.

Quote from TimeSync: Whonix Time Synchronization Mechanism

For example standard Linux adjusts the time with a rate of 0.5ms per second.

With sclockadj2 we would be using the exact same function as NTP does, therefore be even closer to NTP:

Some (slow) progress with sclockadj. Looking into sclockadj2. What is the status with sclockadj2: initial implementation of sclockadj2 using adjtimex syscall by AvdN · Pull Request #4 · Kicksecure/sdwdate · GitHub ?

Stalled. (Already contacted the author.)

Pushed a batch of commits in GitHub - troubadoour/sdwdate: Secure Distributed Web Date; privacy, anonymity and Tor friendly; console time fetcher and daemon; optional graphical user interface etc. Website: https://www.whonix.org/wiki/sdwdate

Could you review the logic? At the moment, time setting mimics the original sdwdate:

  • set time using date → boot and timesync.
  • run sclockadj → after sleep period or sdwdate service restart.

Note. When installing the package from python branch, sdwdate bash is removed. For testing the behaviour of timesync (which reports a failure at this stage), I had to reinstall /usr/lib/sdwdate/restart_fresh.

Forget the note above.
missing files · troubadoour/sdwdate@907cd7c · GitHub installs the required files.