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:
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)
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
__ ### 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?
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.