sdwdate and sdwdate-gui development thread

sdwdate/usr/bin/url_to_unixtime at master · Kicksecure/sdwdate · GitHub wants lots of apparmor permissions. How can this be avoided? @madaidan

AVC apparmor=“DENIED” operation=“exec” profile=“/usr/bin/url_to_unixtime” name=“/usr/bin/x86_64-linux-gnu-gcc-8” comm=“url_to_unixtime” requested_mask=“x” denied_mask=“x”
AVC apparmor=“DENIED” operation=“exec” profile=“/usr/bin/url_to_unixtime” name=“/usr/bin/x86_64-linux-gnu-ld.bfd” comm=“url_to_unixtime” requested_mask=“x” denied_mask=“x”
AVC apparmor=“DENIED” operation=“exec” profile=“/usr/bin/url_to_unixtime” name=“/usr/lib/gcc/x86_64-linux-gnu/8/collect2” comm=“gcc” requested_mask=“x” denied_mask=“x”
AVC apparmor=“DENIED” operation=“open” profile=“/usr/bin/url_to_unixtime//null-/sbin/ldconfig” name=“/etc/” comm=“ldconfig” requested_mask=“r” denied_mask=“r”

This is probably from python attempting to compile ,pyc files for optimization. That script however doesn’t need any performance optimization whatsoever. It is fine and more than fast enough even without compilation.

Attempted to disable ,pyc file creation:

  • python -B
  • environment variable PYTHONDONTWRITEBYTECODE=1
  • sys.dont_write_bytecode = True

But none of that worked.

Is there some way to add in an apparmor profile “good enough - stop reporting further denials”? I guess not as per:

1 Like

sdwdate need to have new design of getting its time corrected, because sdwdate can be turned off through turning off all onion connection from the Tor network itself:

And today the issue is fixed (connecting to onion v3) without a single update or manual configuration to Tor client, This shows clear instability when relying on Tor network to do always the job.

I believe I2P support should be added to the development of sdwdate either when Tor fail to connect to then switch to it or as a replacement to Tor entirely (but we dont need to go to the extreme version now as there are no signs showing the need to do that yet).

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 - #4 by Patrick 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:


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
File “/usr/lib/python3/dist-packages/sdwdate/”, line 1018, in main
File “/usr/lib/python3/dist-packages/sdwdate/”, line 970, in global_files
Path(sdwdate_status_files_folder).mkdir(parents=True, exist_ok=True)
File “/usr/lib/python3.9/”, line 1312, in mkdir
self._accessor.mkdir(self, mode)
PermissionError: [Errno 13] Permission denied: ‘/home/user/sdwdate’

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
File “/usr/lib/python3/dist-packages/sdwdate/”, line 1013, in main
exit_handler(exit_code, reason)
File “/usr/lib/python3/dist-packages/sdwdate/”, line 116, in exit_handler
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

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’.



GETINFO status/circuit-established

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.

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.