sdwdate and sdwdate-gui development thread

It’s now in Whonix testers repository.

Testers welcome! //cc @nurmagoz

1 Like

Merged your commits.

Testing in Whonix-Gateway (VirtualBox).

The line if self.tor_status == 'running': is not necessary, but does it make sense to restart sdwdate when tor is stopped? Any how, minor.

Yes. ⚓ T534 make sdwdate-gui Qubes friendly (sdwdate-gui-qubes)

sdwdate-gui (non-Qubes)

  • exit menu entry missing
    That is on purpose. It was left for testing or debugging. The question is, once sdwdate-gui is thoroughly debugged, do we still want it? It is just commented.in the code.

  • left click does no longer show popup?
    It does, on the second left click, or randomly on the first one, for an obscure reason seemingly created in KDE5, one among other annoying issues.

  • starts with Unexpected error: <class 'NameError'> but otherwise working
    I could not reproduce this one.

The call is done in lines 186 and 215. update_tip('_caller_') runs show_message('_caller_'), which then runs run_popup('_caller_'), under conditions.

This code could be simplified, but I remember trying a couple of times, without much success.

1 Like

Yes.

Yes.

I’d like to say that when installing sdwdate with --no-install-recommends (I don’t like the KDE dependencies) the python3.stem module doesn’t get installed and borks everything. Maybe that should be a required package?

Where did you install it?

troubadour:

The line if self.tor_status == 'running': is not necessary, but does it make sense to restart sdwdate when tor is stopped?

Yes, makes sense because sdwdate would wait (even forever) for Tor to
restart and the log and status symbols would reflect that.

By the way, does the Tor status (disabled) always overrule sdwdate
status? (Should be.)

Debian Stretch via CLI. I seem to remember having the same problem on Jessie, but it’s been awhile.

1 Like

Agreed.

A remark: if tor-control-panel is installed, the Tor status symbol has precedence on the sdwdate status symbol. It was the logic for the condition, assuming tor-control-panel is installed by default.

1 Like

Do you have anon-shared-helper-scripts installed?

python3-stem is a dependency of anon-shared-helper-scripts.

If /usr/lib/anon-shared-helper-scripts/te_pe_tb_check exists and is executable it calls it which then uses python stem.

usr/bin/sdwdate:        prerequisite_status = subprocess.Popen(prerequisite_path, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
usr/bin/sdwdate:    prerequisite_path = '/usr/lib/anon-shared-helper-scripts/te_pe_tb_check'
usr/bin/sdwdate:    if os.access(prerequisite_path, os.X_OK):

sdwdate purposely did not depend on anon-shared-helper-scripts. sdwdate prerequisite_check() is optional.

/usr/lib/anon-shared-helper-scripts/te_pe_tb_check

  • tor_enabled_check
  • pkg_manager_running_check
  • tor_bootstrap_check

Maybe we should do that by default, i.e. make sdwdate depend on anon-shared-helper-scripts?

1 Like

Both added for now but open for arguments.

Yes, installing anon-shared-helper-scripts will get the package installed. I’m actually reporting this issue from memory, sorry if I’m not very helpful on this one.

It seems to me that sdwdate won’t work without anon-shared-helper-scripts so yes, I think so. I’m new to this type of thing, though, so practically anyone else would be in a better position to say.

sdwdate-gui dom0 qrexec policy should be sorted.

sdwdate-gui left click action does nothing in Whonix KDE.

@nurmagoz does sdwdate-gui left click do something in Whonix XFCE?

in xfce its opens the sdw-date list
in KDE (testing version) its also working.

Left click and right click action is the same?

right click has no action whether in KDE or xfce.

1 Like

Left click does nothing for me in KDE.
Left click does nothing for me in XFCE.

Right click always works well for me in KDE.
Right click always works well for me in XFCE.

sdwdate-gui looks a lot better in Whonix XFCE!

(Days of KDE version are probably numbered so no KDE fixes required: User Poll - XFCE vs KDE - KDE Deprecation Considered!)

1 Like

Using Qubes-Whonix, stable proposed updates repo.

I noted today that even when sdwdate-gui was telling me “the clock is fast” etc in logs, and the random time-sync stuff hadn’t completed, it was still possible to download updates via sys-whonix for TemplateVMs.

So, there must be some logic flaw, since all updates should have been blocked until sdwdate finished i.e. jumped a random number of seconds forward or backward first.

Never seen that before.

1 Like

Blocking networking until sdwdate finished isn’t a feature which is enabled by default (yet).

Did you apply instructions from Network Time Synchronization - Whonix?

Sorry, my mistake.

No, I didn’t apply that change - had thought it was by default.

1 Like