Whonix Wiki Download Docs News Support Tips Issues Contribute DONATE

sdwdate and sdwdate-gui development thread

Not sure that is possible. I2P also needs a (somewhat?) correct clock to be able to connect to the I2P network. Maybe it’s even less tolerant to skewed clock than Tor? Therefore we have a similar bootstrap problem. System clock too slow or too fast for I2P being able to connect -> sdwdate cannot cannot use I2P to fetch time from I2P eepsites.

sdwdate improvements have been implemented in git master and Whonix developers repository:

  • sdwdate can now recover, successfully set the system clock even if system clock is so slow (year 2000) or fast (year 2050) so that Tor is unable to connect.
  • The time fetching part of sdwdate (abstracted as separate script url_to_unixtime so it can be more easily confined) is now a python3 requests based implementation with the following features:
    • HTTP header fetching
    • HTTP header parsing (we need the Date: field)
    • HTTP 1.0 and HTTP 1.1 compatibility
    • TLS support
    • socks support (for Tor configuration and stream isolation)

Issue of Most Onions Down due to a Denial of Service Attack on the Tor Network / sdwdate synchronisation fails, sometimes works has not been addressed due to lack of a concept how sdwdate could fetch time if most onions are down most of the time.




Could use some help with apparmor / seccomp / systemd / sandbox-app-launcher confinement.

//cc @madaidan

1 Like

This was resolved thanks to:

2 Likes

access control disabled, clients can connect from any host

That comes from this:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-sdwdate-gui’

See also below.

I guess don’t fix if not broken. We possibly need to redesign this for wayland anyhow. See also above.

sdwdate-gui wont show up in the taskbar on non-kicksecure-xfce DE like e.g Gnome


Confusing Thing: (Whonix-WS)

Permission Denied because root not used:

user@host:~$ sdwdate --verbose --debug
2022-05-31 17:05:34 - sdwdate - INFO - sdwdate started. PID: 42564
Traceback (most recent call last):
File “/usr/bin/sdwdate”, line 10, in
sdwdate.main()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 1018, in main
global_files()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 970, in global_files
Path(sdwdate_status_files_folder).mkdir(parents=True, exist_ok=True)
File “/usr/lib/python3.9/pathlib.py”, line 1312, in mkdir
self._accessor.mkdir(self, mode)
PermissionError: [Errno 13] Permission denied: ‘/home/user/sdwdate’
user@host:~$

But sdwdate should not run as root:

user@host:~$ sudo sdwdate --verbose --debug
2022-05-31 17:05:18 - sdwdate - INFO - sdwdate started. PID: 42562
2022-05-31 17:05:18 - sdwdate - ERROR - Exit error… sdwdate should not be run as root!
2022-05-31 17:05:18 - sdwdate - INFO - Exiting with exit_code ‘1’ because or reason ‘sdwdate should not be run as root.’.
2022-05-31 17:05:18 - sdwdate - INFO - sdwdate stopped by user or system.
write_status unexpected error: <class ‘NameError’>
2022-05-31 17:05:18 - sdwdate - INFO - sclockadj process not running, ok.
2022-05-31 17:05:18 - sdwdate - INFO - sleep process not running, ok.
Traceback (most recent call last):
File “/usr/bin/sdwdate”, line 10, in
sdwdate.main()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 1013, in main
exit_handler(exit_code, reason)
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 116, in exit_handler
Path(sleep_long_file_path).unlink(missing_ok=True)
NameError: name ‘sleep_long_file_path’ is not defined

?

1 Like

4 posts were split to a new topic: sdwdate - WARNING - Clock got changed by something other than sdwdate. sleep_time_seconds: 6040 time_delta: 6043 time_passed: -3

https://www.kicksecure.com/wiki/Dev/sdwdate#sdwdate_linux_user_account

1 Like

Clarify more 1/10000 in sdwdate message log.

1 Like

Done in git.

1 Like

Created for it:

1 Like

When using suspend and resume in Qubes-Whonix if too much time passed, Tor circuits will be invalid. This will result in sdwdate failing.

Tor control protocol (“Tor API”) reports everything being okay.

sudo -u sdwdate /usr/libexec/helper-scripts/onion-time-pre-script 

__ ### START: ### /usr/libexec/helper-scripts/onion-time-pre-script
__ Status: Subsequent run after boot.
__ Static Time Sanity Check: Within minimum time ‘Fri Feb 18 00:00:00 UTC 2022’ and expiration timestamp ‘Tue May 17 10:00:00 UTC 2033’, ok.
__ Tor circuit: established
__ Tor Consensus Time Sanity Check: Clock within consensus parameters consensus/valid-after 2022-09-11 18:00:00 and consensus/valid-until 2022-09-11 21:00:00.
__ Conclusion: Tor already reports circuit established.
__ ### END: ### Exiting with exit_code ‘0’ indicating ‘success’.

sys-whonix…

tor-prompt

GETINFO status/circuit-established

250-status/circuit-established=1
250 OK

GETINFO status/bootstrap-phase

250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY=“Done”
250 OK

I suspect the information in Tor is actually cached and just returned when asked for. Tor doesn’t actually re-check this information.

Is there any way to force Tor to re-check this using Tor control protocol?

//cc @nyxnor

Read all the GETINFO commands, nothing that I think 100% would work.
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1126

GETINFO network-liveness also does not work.

This project tries to act based on tor logs, but instead of a file, we can use tor-ctrl -w -- SETEVENTS WARN for only relevant events.

But found no command alone that could check if tor is really working.
Because there is also that fact that all streams that are using a circuit that has a failing guard, will still try that guard and fail. And even if all guards are unreacheable, tor does not report that as a boolean, but on logs.

Anyway, asking upstream could be the best.

1 Like

This is the upstream bug report:

The ticket was closed because of this:

So the original issue was ignored and not forwarded elsewhere.

Yeah. A Tor issue reported again here:

Nick Mathewson :bridge_at_night: @nickm added
Close in favor of Arti
label 2 months ago

So Tor Project won’t fix it. Though, it might be fixed when Arti is released or at least then it could be re-tested and re-reported.

Debian bug report:
broken Tor connection after extended suspend/resume - Tor’s systemd service should restart Tor on resume/thaw after sleep/hibernate