sdwdate-gui for Qubes. Testers wanted (developers welcome)

dragonfly · December 24, 2023, 6:34pm

Not sure if this is the best place to post, but I’ve been experiencing an issue with sdw-date gui widget on Qubes 4.2 using Whonix 17 for the last couple of days where no running workstation vm will show up in the sdw-date widget, only sys-whonix.

Is this the result of a planned change? I think it started happening after the last big Whonix 17 update (I think I’m on the testing repo). Should I be worried about this?

I’ve also been dealing with the problem described in the Qubes github issue #8672 (I can’t post links) regarding the gui widget.

Edit: just noticed this topic was 5 years old…my bad.

Patrick · December 25, 2023, 7:27pm

github.com/QubesOS/qubes-issues

"Focus stealing prevention" in Window Manager Tweaks prevents interaction with Whonix Time Synchronization Monitor widget (sdwdate-gui) until other sys-whonix window opened

opened 12:23PM - 30 Oct 23 UTC

UndeadDevel

T: bug C: gui-virtualization C: desktop-linux-xfce4 P: default needs diagnosis affects-4.1 affects-4.2

### Qubes OS release Qubes 4.1.2 Whonix 16 Also on (it's worse with these):… Qubes 4.2 Whonix 17 ### Brief summary I've noticed that since I disabled sys-whonix autostart at boot of QubesOS there are issues with the Time Synchronization Monitor (TSM) in the Notification Area of the panel (top panel right side by default). The issues seem to be: 1. it either takes longer for the full initialization to complete (lock with full circle icon) or the notification icon doesn't show the correct status (this point looks to be fixed in 4.2 with Whonix 17) 2. interacting with the notification icon is not possible, because the little popup that appears when clicking on it, immediately disappears again. (worse on 4.2 with Whonix 17) For Qubes 4.1.2: this only occurs when starting, e.g. a new Whonix WS DVM while sys-whonix is not running, such that it will automatically start sys-whonix as well. If sys-whonix was already running and the full lock icon displayed then starting new DVMs does not cause this issue; starting sys-whonix alone (e.g. autostart on boot or manually later) does not cause this issue if one waits for "full lock" of the icon before starting sys-whonix-connected VMs. For Qubes 4.2: occurs on every observed start of sys-whonix (the popup window closes as soon as it's opened), but turning off "focus stealing prevention" in the Window Manager Tweaks dom0 app fixes the issue (that feature is pretty important in QubesOS, though, so it would be nice to fix this without requiring that feature to be off). This issue can also be fixed by running the "Reload Firewall" or "Reload Tor" apps of sys-whonix, though the former seems to be more efficient in terms of time until full lock is displayed. Edit: Actually, opening any window, including a regular terminal, from `sys-whonix` will fix this issue. ~~I've also noticed that when disconnecting Whonix WS DVMs from sys-whonix and reconnecting them to it later, those don't always show up in the TSM again, even though they do regain network access through sys-whonix (as per Qube Manager), though this may be a different problem.~~ Edit: now reported under #8798 ### Steps to reproduce Put a checkmark on "Activate focus stealing prevention" in Window Manager Tweaks, Focus tab. On Qubes 4.1: Launch Whonix WS DVM without sys-whonix running (should autostart together). On Qubes 4.2: Launch sys-whonix Observe and try to interact with the TSM icon in the Notification Area of the panel. ### Expected behavior Normal TSM functionality ### Actual behavior Interaction not possible, needs fix via e.g. "Reload Firewall" or opening a terminal window in sys-whonix to work normally again.

No.

Valid Compromise Indicators versus Invalid Compromise Indicators

dragonfly · December 25, 2023, 7:40pm

Okay, but it seems that this is still relevant to the security of Qubes-Whonix, as it’s now not obvious if sdwdate has completed the synchronization for the workstation.

IIUC the new issue tracker is basically this forum; should I open a new topic for this issue, as it’s distinct from the one already reported to the qubes-os github?

Patrick · December 25, 2023, 8:24pm

No additional reports required.

Patrick · December 25, 2023, 8:27pm

This is probably fixed with this commit:

(Whonix is based on Kicksecure.)

This fix is now in all Whonix 17 repositories.

(This was fixed using “Instant Package Migration” (link).)

dragonfly · December 25, 2023, 11:19pm

Confirmed fixed by the update on my end, thank you!

dragonfly · December 26, 2023, 12:21pm

It seems that update had some negative side effects (could also have been the prior update): when sdwdate fails to complete for a workstation, I wait for it to complete on the gateway and after that (as I’ve done many times in the past) use the widget to “Restart sdwdate” on that workstation qube; this used to work in the past, but now I’m getting the following error:
whonix_error

In my policy files I see:

/etc/qubes/policy.d/80-whonix.policy:whonix.GatewayCommand +restart @tag:anon-gateway @tag:anon-vm      allow  autostart=no
/etc/qubes/policy.d/80-whonix.policy:whonix.GatewayCommand +stop    @tag:anon-gateway @tag:anon-vm      allow  autostart=no
/etc/qubes/policy.d/80-whonix.policy:whonix.GatewayCommand +showlog @tag:anon-gateway @tag:anon-vm      allow  autostart=no

The tags on the gateway and workstation check out, so it seems that the argument restart is expected, but the actual argument given is _restart_.

In fact, changing that policy (first quoted line) to have a _restart_ argument instead of restart will get rid of the error message, but it still won’t restart sdwdate on the workstation.

Patrick · December 26, 2023, 11:12pm

Fixed in all Whonix 17 repositories.

Patrick · December 29, 2023, 3:28pm

github.com/QubesOS/qubes-issues

Disconnecting and reconnecting a VM from sys-whonix or forcing a restart of sys-whonix does not return connected VMs to sdwdate-gui widget

opened 02:09PM - 28 Dec 23 UTC

UndeadDevel

T: bug C: Whonix P: default needs diagnosis affects-4.1 affects-4.2

### Qubes OS release 4.2, Whonix 17 (also occurred on 4.1.2 with Whonix 16) … ### Brief summary Forcing a `sys-whonix` restart via Qube Manager or setting the netVM of a `sys-whonix`-connected qube to "None" and back to `sys-whonix` does not bring those qubes back to the `sdwdate-gui` widget in the tray. Only rebooting those workstations will list them in that widget again. ### Steps to reproduce Either force reboot of `sys-whonix` or disconnect a connected qube and reconnect it via netVM settings. ### Expected behavior All qubes connected to `sys-whonix` show up in the `sdwdate-gui` tray widget. ### Actual behavior Only qubes that were started after `sys-whonix` was started and were never disconnected show up in that widget.

Patrick · December 29, 2023, 4:13pm

sdwdate-qui-qubes is currently complex. It has a two way communication through multiple qrexec calls. A better design was discussed in ⚓ T930 whonix.SdwdateStatus service starts VMs that were killed but is unlikely to get implemented without a contributors.

Patrick · December 29, 2023, 4:20pm

I am wondering if I could request a few Qubes github issues re-title to make these easier to locate? @adw

Impossible to interact with Whonix Time Synchronization Monitor widget (sdw-date gui) until firewall or tor restart · Issue #8672 · QubesOS/qubes-issues · GitHub fix spelling to sdwdate-gui
Renaming `sys-whonix` results in `Denied whonix.NewStatus+status from dispXXXX to sys-whonix` · Issue #8695 · QubesOS/qubes-issues · GitHub add (sdwdate-gui)

Something like this.

If that is OK I might have a second round of ticket rename requests. I want to group them all together to perhaps sketch a new design. But it won’t be that many sdwdate-gui ticket so don’t worry.

adw · December 29, 2023, 9:40pm

Yes, of course!

Looks like the issue opener already fixed this one before I had a chance.

Done. Thanks for letting me know!

Of course, please feel free. No worries.