We have someone working on this now. Some thoughts on the design...

• sdwdate-gui currently is only for a single VM. It's old right click menu looks like that:

-------------------
Open sdwdate's log
-------------------
Restart sdwdate
Stop sdwdate
Exit
-------------------

A green, yellow or red systray symbol is shown depending on the state.

• The new implementation for Non-Qubes-Whonix should look the same as currently is in Non-Qubes-Whonix. There probably should be a command line switch for sdwdate-gui's two different modes? Or should there be better two different Non-Qubes-Whonix sdwdate-gui and Qubes-Whonix sdwdate-gui? Whatever makes more sense code maintenance wise. I guess a new tool /usr/bin/sdwdate-gui-qubes would make more sense than trying to share code in /usr/bin/sdwdate-gui?

• Probably no separate package required. (Package sdwdate-gui-qubes not requried.) Just add to sdwdate-gui (and modify sdwdate for qrexec).

• There could be theoretically an "infinite" (large) amount of Whonix-Workstations booting up.

• When a Whonix-Workstation boots up, it issues an qrexec call to Whonix-Gateway to register itself so it gets added to Whonix-Gateway's sdwdate-gui systray.

• What if Whonix-Workstation is shut down, killed ungracefully, or crashed? Then it cannot deregister itself. How does Whonix-Gateway's sdwdate-gui systray notice and remove it? Any idea? Should Whonix-Gateway "ping" the Whonix-Workstations every X seconds? And if they don't answer, remove them from the menu? What if Whonix-Workstations just hang and come back later? The case has to be covered if a Whonix-Workstation sends a updated sdwdate status which was not previously registered.

• Implement qrexec status notification where? sdwdate should use qrexec to sdwdate-gui on sys-whonix? (Skip qrexec calls on Non-Qubes-Whonix and continue to use the current implementation.)

• Whonix-Gateway has its own sdwdate-gui status.

• This explanation is a bit redundant. Since quite hard to say for me in English, I rephrase the same various times.
• If gateway is in status "red" -> use red color.
• If gateway is in status "yellow" -> use yellow color.
• If any of the workstations is in status "red" -> use red color.
• If any of the workstations is in status "yellow" -> use red color.
• If there are mixed statuses (one workstation green, another one yellow, another one red), use the worst status.
• Red is the worst status, yellow is better, green is best.
• Red has always priority over yellow
• Yellow has always priority over green.
• Show only green if Whonix-Gateway and all Whonix-Workstations (if any) are green.

• Each entry in sdwdate-gui should show the name of the Whonix-Workstation (qubesdb-read /name) and an icon showing its status.

• The right click menu of the new Qubes-Whonix sdwdate-gui. Generic description:

----------------------------------------------------------
red|yellow|green symbol | sys-whonix
----------------------------------------------------------
red|yellow|green symbol | anon-whonix
red|yellow|green symbol | anon-web
red|yellow|green symbol | anon-mail
----------------------------------------------------------

• The right click menu for the new Qubes-Whonix sdwdate-gui. Specific example:

----------------------------------------------------------
green symbol  | sys-whonix
----------------------------------------------------------
yellow symbol | anon-whonix
green symbol  | anon-web
red symbol    | anon-mail
----------------------------------------------------------

• Once hovering over a menu point such as "anon-whonix", open a sub menu showing the same as the old right click menu?

• Please keep in mind, that in a later version we might extend the functionality of sdwdate-gui to a Tor controller. Similar to what Vidalia did in past (but much more lightweight, less features). A tool that would also show the state of Tor connectivity. Probably not before Whonix 15 or 16.

• Does that sound like sane usability? Do we have any access to any usability designer?

@marmarek is there some qubesdb-read to find out from anon-whonix that its NetVM is sys-whonix?

(Required to qrexec target variable. Trying to cover the case where one is using multiple Whonix-Gateway's.)

In T534#13990, @Patrick wrote:

@marmarek is there some qubesdb-read to find out from anon-whonix that its NetVM is sys-whonix?

(Required to qrexec target variable. Trying to cover the case where one is using multiple Whonix-Gateway's.)

Currently there isn't, but can be easily added, even as a stable update to Qubes 3.2.
On the other hand, better would be to control it using qrexec target= option - then, Whonix-Workstation do not need to know the name of its Whonix-Gateway (better privacy). And at the same time we get strict policy that Whonix-Workstation can connect only to specific Whonix-Gateway. It would look like this:

dom0$ cat /etc/qubes-rpc/policy/whonix.sdwdate-gui
other-whonix  $anyvm allow,target=other-whonix-gw
anon-whonix $anyvm allow,target=sys-whonix
# in Qubes 4.0:
$tag:whonix $anyvm allow,target=sys-whonix
# or even (works also in Qubes 3.2), but probably bad idea:
$anyvm $anyvm allow,target=sys-whonix

A problem with this approach - needs to be manually synchronized when configuring multiple Whonix-Gateways. On the other hand, some policy for this qrexec will be needed anyway.

Playing with tags.

@marmarek
Am I correct saying that the default anon-whonix created during installation of Qubes 4.0 contains a tag anon-vm (like Whonix templates containing whonix-updatevm)? When creating a second Whonix workstation, only the default created-by-dom0 tag is listed.

For a single gateway / multiple workstations setup, have done the following:

Add tag gateway for sys-whonix
Add tag anon-vm for newly created workstations.
Add policy /etc/qubes-rpc/policy/whonix.test

$tag:anon-vm $anyvm allow,target=sys-whonix

or

$tag:anon-vm $tag:gateway allow

Both work.

In sys-whonix, create a command /usr/local/etc/qubes-rpc/whonix.test

The new command can be run from any anon-vm with

qrexec-client-vm sys-whonix whonix.test+"[argument]"

It looks fine, but we still need to manually add a tag for each newly created anon-vm. Would there be a way to automate the process ?

Some progress on this one. A summary without literature.

The new GUI is partially done (no icons for the reasons below).

sys-whonix (or the name found in qubesdb)
-------------------------------------------------
anon-whonix-1                                                  
anon-whonix-2
anon-whonix-3

The anon-vm list is updated in the menu as they start.

submenu when hovering on the vm name:

Show status
-------------------------------------------------
Open sdwdate's log
-------------------------------------------------
Restart sdwdate
Stop sdwdate

Show status is implemented, showing the last -partial- message for the corresponding vm in the gui popup.

No status tooltip, only a general one.

For now, the qrexec commands are issued from the workstations sdwdate-gui, for practical reasons, the main one being that it's easy to restart sdwdate from there.

Obviously they'll have to be in sdwdate. They are some issues regarding the format of the argument in qrexec-client-vm sys-whonix whonix.test+"[argument]" when it reaches the target vm. It's sanitized, no problem there, it can be parsed, but it's truncated at 51 bytes, which limits what we can pass.

Two possible solutions.
Use the yaml key instead of the message in its entirety (a big change in sdwdate), or perhaps use a file argument as per https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-example---with-argument-usage. It would probably require a two-way communication, which anyhow will be needed at some stage .

Or whatever you might suggest.

In T534#13994, @marmarek wrote:

In T534#13990, @Patrick wrote:

@marmarek is there some qubesdb-read to find out from anon-whonix that its NetVM is sys-whonix?

(Required to qrexec target variable. Trying to cover the case where one is using multiple Whonix-Gateway's.)

Currently there isn't, but can be easily added, even as a stable update to Qubes 3.2.

That would help.

Awesome progress! :)

troubadour (troubadour):

For now, the qrexec commands are issued from the workstations sdwdate-gui, for practical reasons, the main one being that it's easy to restart sdwdate from there.

Obviously they'll have to be in sdwdate.

Possibly, yes. Necessarily, maybe not. Keeping all the "if Qubes then"
logic outside of sdwdate may also be an option. There could be an
external tool sdwdate-message-sender or so (part of package sdwdate) if
that was to help with ease of development, debugging, code cleanness.
sdwdate-message-sender could inotifywait read the sdwdate status files
and then translate that to qrexec notifications sent to
Qubes-Whonix-Gateway.

I was also wondering to keep the current sdwdate-gui as is, and then
autostart it in Non-Qubes-Whonix only. Just to keep that sdwdate-gui
code small, simple and for reference. (And to manually start sdwdate-gui
even in Qubes for debugging purposes.)

The sdwdate-gui-qubes version could be a separate program (part of
sdwdate-gui package still), which only gets auto-started in
Qubes-Whonix-Gateway's. I guess there is not that much code to share
between the both? Just brainstorming. Whatever you think works best.

They are some issues regarding the format of the argument in qrexec-client-vm sys-whonix whonix.test+"[argument]" when it reaches the target vm. It's sanitized, no problem there, it can be parsed, but it's truncated at 51 bytes, which limits what we can pass.

Why is it truncated? @marmarek

I guess it can be solved somehow? I mean, qrexec can also be used to
transfer files of multiple GB or tens of thousands of lines of text
(Qubes secure copy and paste is based on qrexec).

In https://phabricator.whonix.org/T534#13994, @marmarek wrote:

> In https://phabricator.whonix.org/T534#13990, @Patrick wrote:
>
> > @marmarek is there some `qubesdb-read` to find out from `anon-whonix` that its NetVM is `sys-whonix`?
> >
> > (Required to qrexec target variable. Trying to cover the case where one is using multiple Whonix-Gateway's.)
>
>
> Currently there isn't, but can be easily added, even as a stable update to Qubes 3.2.


That would help.

Indeed!

(But without that feature - give that Qubes R3.2 will be deprecated in 1
year [my last update], I wouldn't go into gymnastics working around this
in Whonix then. We'd just wait for Qubes R4 then.)

Obviously they'll have to be in sdwdate. They are some issues regarding the format of the argument in qrexec-client-vm sys-whonix whonix.test+"[argument]" when it reaches the target vm. It's sanitized, no problem there, it can be parsed, but it's truncated at 51 bytes, which limits what we can pass.

You can send the message inside the connection. argument is really useful when you want to setup qrexec policy based on its value (like allow some messages but not others). If you just want to send a message, pipe it to service stdin on one side, and receive from stdout on the other.

@marmarek is there some qubesdb-read to find out from anon-whonix that its NetVM is sys-whonix?
(Required to qrexec target variable. Trying to cover the case where one is using multiple Whonix-Gateway's.)

Working on it. Right now you can use some placeholder ($default in R4.0) and redirect it to appropriate VM in qrexec policy. Downside of this solution - you need to keep qrexec policy in sync with netvm setting manually.

As for qubesdb - I'm considering /qubes-netvm or /qubes-netvm-name for that. But I have a problem: we already use various /qubes-netvm-* for settings inside of netvm (like what network range should be provided to other VMs). Not for information about VM's uplink. Any better idea for the entry name?

troubadour

For now, the qrexec commands are issued from the workstations sdwdate-gui,
for practical reasons, the main one being that it's easy to restart sdwdate from there.
Obviously they'll have to be in sdwdate.

Patrick

Possibly, yes. Necessarily, maybe not. Keeping all the "if Qubes then"
logic outside of sdwdate may also be an option.

That would help a lot. There are not that many "if Qubes then" in sdwdate -- actually we also check if we are not in sys-whonix --, but when it comes to run the qrexec command in sdwdate, the problem begins. Have tried all sort of things to get the call, Popen or even os.system command working in sdwdate, to no avail, although call works in many other places.

There could be an
external tool sdwdate-message-sender or so (part of package sdwdate) if
that was to help with ease of development, debugging, code cleanness.

That's what I was thinking of when starting. The tool would be a subset of sdwdate-gui. At the moment I'm using sdwdate-gui "as is" plus the qrexec command.

I'll try to describe the current setup (working).

• in anon-whonix external tool: if is_qubes and is_anon_vm and I have a new sdwdate status --> "qrexec sys-whonix new-status-rpc(my name)"
• in sys-whonix, new-status-rpc writes the calling vm name to a file: "echo $1 >new-status-file"
• in anon-whonix, the script sdwdate-status-rpc: "cat /var/run/sdwdate/status"
• in sys-whonix, sdwdate-gui watches new-status-file. On change --> "qrexec vm-name sdwdate-status-rpc > status-file". Then pickle.load status-file and the following logic is common with sys-whonix status_changed.

Hope this is clear enough. It's almost easier to write the code than to describe it.

This way, we leave sdwdate untouched.

The sdwdate-gui-qubes version could be a separate program (part of
sdwdate-gui package still), which only gets auto-started in
Qubes-Whonix-Gateway's. I guess there is not that much code to share
between the both? Just brainstorming. Whatever you think works best.

Yes, the code in sdwdate-gui-qubes has a lot of additions and cannot be adapted to non-qubes environments. So we could have an additional module in the same package. It would be up to you installing the right one.

>>! In T534#15414, @marmarek wrote:

As for qubesdb - I'm considering /qubes-netvm or /qubes-netvm-name for that. But I have a problem: we already use various /qubes-netvm-* for settings inside of netvm (like what network range should be provided to other VMs). Not for information about VM's uplink. Any better idea for the entry name?

Perhaps /qubes-gateway or /qubes-gateway-name. I'm using a tag gateway for the policies in dom0. It would be consistent with Whonix.

Update.

The submenu commands are implemented. Looks nice and handy.

As a reminder, the Whonix-Workstation are registered as they start. In the systray menu, the icon besides the workstation name is the one from sdwdate status.

Now, we have to update the systray icon to reflect the worst case in the running workstations. As the icons are passed by path/name, it's not easy to sort, unless we reproduce the icons names in sdwdate-gui.

The icons path could be in sdwdate-gui (logically they belong there), and the icon level would be passed from sdwdate as a number ( 0 = success, 1 = restricted, 2 = error).

Does that sound sensible?

In T534#15420, @troubadour wrote:

Update.

The submenu commands are implemented. Looks nice and handy.

Wow!

As a reminder, the Whonix-Workstation are registered as they start. In the systray menu, the icon besides the workstation name is the one from sdwdate status.

What happens if a workstation is killed, and then later restarted? Any other cases where any (delayed) re(starts) corner cases could lead to something strange? Like when the workstation sends sdwdate-gui info to the gateway before the gateway is ready or is that pretty unlikely?

Now, we have to update the systray icon to reflect the worst case in the running workstations. As the icons are passed by path/name, it's not easy to sort, unless we reproduce the icons names in sdwdate-gui.

The icons path could be in sdwdate-gui (logically they belong there), and the icon level would be passed from sdwdate as a number ( 0 = success, 1 = restricted, 2 = error).

Does that sound sensible?

Passing which icon by passing a number through qrexec sounds very reasonable, yes, why not.

In T534#15415, @troubadour wrote:

Then //pickle.load status-file

Could a compromised workstation use this to execute code on the gateway?

Probably no. But I,m not an expert in security or attacks.

pickle load deserialize an object, in our case a DICTionary. Anything not in that form would raise an exception. Even if a dictionary element contained some code, it would be displayed as such (or raise an exception for the [icon] entry).

In T534#15424, @troubadour wrote:

Probably no. But I,m not an expert in security or attacks.

pickle load deserialize an object, in our case a DICTionary. Anything not in that form would raise an exception.

How do you ensure that? Normally pickle.load would gladly deserialize any object, even if that results in executing code inside of it. See https://docs.python.org/3/library/pickle.html
Better use json or such if really a structure (rather than a single value) is needed.

What happens if a workstation is killed, and then later restarted?

The workstations gracefully notify the gateway when they shut down, thus being de-registered in sdwdate-gui-qubes, and re-registered whenever they restart.

That is for normal shutdown-reboot-poweroff. If they are crashed/killed, the gateway has no way to know (yet).

Any other cases where any (delayed) re(starts) corner cases could lead to something strange? Like when the workstation sends sdwdate-gui info to the gateway before the gateway is ready or is that pretty unlikely?

That seems very unlikely in a normal start sequence (gateway booting before workstation). Anyhow, the setup being heavily tested during this phase, we'll see if I manage to defeat it.

In T534#15425, @marmarek wrote:

In T534#15424, @troubadour wrote:

Probably no. But I,m not an expert in security or attacks.

pickle load deserialize an object, in our case a DICTionary. Anything not in that form would raise an exception.

How do you ensure that? Normally pickle.load would gladly deserialize any object, even if that results in executing code inside of it. See https://docs.python.org/3/library/pickle.html
Better use json or such if really a structure (rather than a single value) is needed.

Thanks for the clarification. I was not sure. Will use json instead.

Relevant code excerpt sdwdate.

def write_status(icon, msg):
    sdwdate.status['icon'] = icon
    sdwdate.status['message'] = msg

        with open(sdwdate.status_path, 'w') as f:
            json.dump(sdwdate.status, f)

Relevant code excerpt sdwdate-gui.

            with open(self.status_path, 'r') as f:
                status = json.load(f)
f.close()

        icon = self.icon[self.icons.index(status['icon'])]
        self.setIcon(QtGui.QIcon(icon))
        self.message = status['message'].strip()

        self.setToolTip('%s\n%s' %(self.title, self.message))
self.update.update_tip.emit()

Any security concerns about that? @marmarek

Json handling looks fine. Not sure about using the data loaded from there - for example if self.message require sanitization. AFAIR some Qt widgets support html formatting, so it may be undesirable to allow that.

BTW f.close() is unnecessary when using with syntax.

sdwdate-gui-qubes will be shortly ready for packaging.

There are files for the gateway, files for the workstations, none for non-qubes environment. At this stage, for review, it would be easier to make a standalone package before merging in sdwdate-gui.

In T534#15444, @troubadour wrote:

sdwdate-gui-qubes will be shortly ready for packaging.

There are files for the gateway, files for the workstations, none for non-qubes environment. At this stage, for review, it would be easier to make a standalone package before merging in sdwdate-gui.

It was actually easier to merge directly, if only for the new user sdwdate-gui created in postint.

But there is an issue I might need some help with. When making the packages (make deb-icup), the files in /etc/qubes/rpc are not installed. I cannot list all the things I have checked/tried, to no avail. The other files are installed, including /usr/lib/qubes/notify-shutdown. Have been wondering if there could be an issue with qubes folders...

The package should be complete on github.
https://github.com/troubadoour/sdwdate-gui

After installation, it is -probably- required to enable shutdown-notify systemd service in whonix-ws.

In dom0, add tags

qvm-tags sys-whonix add gateway

For each new anon-vm

qvm-tags vm-name add anon-vm

In /etc/qubes-rpc/policy add policies

• whonix.GatewayCommand and whonix.SdwdateStatus

$tag:gateway $tag:anon-vm allow
$anyvm $anyvm deny

• whonix.NewStatus

$tag:anon-vm $tag:gateway allow
$anyvm $anyvm deny

Only small issues for now.

• please grep for rm /var/run/sdwdate/success and make that rm -f /var/run/sdwdate/success to avoid failing when the file does not exist
• What if NAME set nothing, i.e. NAME="". What would happen?

(Somehow phabricator markup broken when writing NAME= in within code tags, weird.)

NAME $(/usr/bin/qubesdb-read /name)
/usr/bin/qrexec-client-vm sys-whonix whonix.NewStatus+$NAME" shutdown"

This could use some defensive code. This may happen if qubesdb-read refuses to reply such as when qubesdb is being upgraded or when it is broken due to a bug. Even if not fixable, the result should not be a crash or so. (Dunno what would happen.)

• check_output(['qubesdb-read', '/name']).decode().strip() - this also needs some kind of protection in case qubes-db does not work. You could simulate that case by using:

sudo service qubes-db stop

Which would then result in:

qubesdb-read /name

Failed connect to local daemon

By checking if exit code is non-zero.

• Also in case of a bug qubesdb-read /name might return "", i.e. nothing.

Implemented some defensive code against qubes-dband qubes-qrexec-agent just in case. Now if one or both of those services stop, it just ensures that the sdwdate-gui programs don't crash, and that's it.

Please keep in mind, that in a later version we might extend the functionality of sdwdate-gui to a Tor controller. Similar to what Vidalia did in past (but much more lightweight, less features). A tool that would also show the state of Tor connectivity. Probably not before Whonix 15 or 16.

I do not remember what Vidalia did exactly, never used it much. There was probably some circuit changing and other exotic features.

To begin with a Tor controller, it looks feasible (with a dedicated submenu under sys-whonix menu entry) to run anon-connection-wizard and restart-tor-gui from the systray icon.

In T534#15447, @troubadour wrote:

Implemented some defensive code against qubes-dband qubes-qrexec-agent just in case. Now if one or both of those services stop, it just ensures that the sdwdate-gui programs don't crash, and that's it.

Great!

Please keep in mind, that in a later version we might extend the functionality of sdwdate-gui to a Tor controller. Similar to what Vidalia did in past (but much more lightweight, less features). A tool that would also show the state of Tor connectivity. Probably not before Whonix 15 or 16.

Sounds awesome!

If possible: it should only show Tor restart gui / anon-connection-wizard if these are installed. Otherwise not show such a menu entry.

Perhaps mostly external applications that get tied together in sdwdate-gui? Like a plugin structure (without inventing overkill)?

I do not remember what Vidalia did exactly, never used it much. There was probably some circuit changing and other exotic features.

I still remember it and found some representative Vidalia screenshots.

• main menu - http://i1-win.softpedia-static.com/screenshots/Vidalia-for-Windows_1.png - very old program, probably should not reinvent, probably don't need all of that
• world map - http://i1-mac.softpedia-static.com/screenshots/Vidalia_2.jpg - we probably don't need to reinvent (all) - we already install https://packages.debian.org/stretch/onioncircuits by default. Perhaps we let users run onioncircuits from it?
• a nice log viewer: https://obrazki.elektroda.pl/7662399900_1336128587.png
• a bandwith graph - http://tr3.cbsistatic.com/hub/i/r/2013/11/25/ad67be71-1dbe-451a-9e43-be5acf67382a/resize/620x485/6b49afbfe4f9f738cfe5a90145ee471e/vidalia_figure_b.112513.png - not sure if useful

I guess most importantly (and only?) (simple...): "Does Tor work or not? If not, what's the status? Any advice?" / "reconfigure using anon-connection-wizard". That would be a superb start, I guess.

More complex stuff such as configuration of hidden services could be done later if ever.

• (How onionshare does it seems the way to go. The user doesn't have to create the hidden service manually. And the remaining instructions like https://www.whonix.org/wiki/Next#onionshare could be automated using qrexec. Similarly it would be good if there was a simple way to setup a hidden web server. The only thing I don't like is that with onionshare's way the hidden service private key ends up inside the workstation.)

We could use some wider input such as from the tor-talk mailing list (what features would be useful for a Tor controller, Vidalia replacement) as well as from some usability designer.

it: Once sdwdate-gui is also a Tor controller, we'd need to rename it? Any generic use case / generic name possible (i.e. not Whonix in its name)?

Have pushed an updated version with Restart Tor and Anon Connection Wizard commands from the menu, so you can have an idea of the look and feel. This is of course not written in stone. The standalone restart-tor-gui was updated for testing. https://github.com/troubadoour/restart-tor-gui

So we have a frame where we could put theoretically anything. There will definitely be a question of usability, but for the time being:

I guess most importantly (and only?) (simple...): "Does Tor work or not? If not, what's the status? Any advice?" / "reconfigure using anon-connection-wizard". That would be a superb start, I guess.

Yes, the next step should be trying to get a comprehensive tor status with recommendations and perhaps some tor log in case of failure.

If possible: it should only show Tor restart gui / anon-connection-wizard if these are installed. Otherwise not show such a menu entry.

Done. (with a TODO)

Some progress here.

The sdwdate-gui icon is updated according to Tor status. Which, before any other question, leads to the name sdwdate-gui vs ??. It will be a big change in the package, so before going farther, it would be nice to agree on a name.
I'm not good on that matter. A bit lazy perhaps, Anon Controller would do the job if only because there is GUI with the existing tools in the pipeline. Some other people could have input.

A couple of remarks about the current version.

In sys-whonix, Tor status message GUI is shared with sdwdate message, meaning that when showing Tor status and restarting sdwdate (or it restarts by itself), the latter will pop (unless Tor is stopped or disabled) . Might be petty, but when used intensively, it can be annoying. I have already a dedicated show_tor_message that gets the status icon too. Wondering if it's worth implementing the logic for a separate popup.

Second and more important, the precedence of Tor not running vs Tor disabled (DisableNetwork 1). When Tor is disabled, we might or we might not have an internet connection. Obviously, after setting Disable in Anon Connection Wizard, there is none because we stop Tor too. I guess this issue could be the subject of another (umpteenth) thread.

Added the relevant icon in show_message (after resizing the sdwdate icons from mediawiki, the original are huge).

A new Tor controller GUI.

https://github.com/troubadoour/tor-control-panel

The package is standalone, not depending on any other Whonix package, except anon-connection-wizard, which can be checked on loading.

After the last update, the package can be run from sdwdate-gui menu.

It's a tabbed application. Considering the number of options that might end up in there, I believe that it is the best layout. The opening tab is the one really needed by the user, showing Tor status and configuration, plus access to useful commands.

It's far from being completed. Though it's running, there is most likely some debugging left.

Before adding more feature and perhaps publishing some screenshots, would be nice to have you point of view.

Update, after my post in the forum.
https://forums.whonix.org/t/testers-wanted-blocking-networking-until-sdwdate-finished-status-of-sdwdate-gui/5372/3

When putting sdwdate-gui-qubes under stress, I have been chasing a segmentation fault.
It was due to a poorly written context menu. Fixed.

Currently, sdwdate-gui-qubes is being bombarded with sys-whonix and five anon-vm restarting
sdwdate at a random time interval ranging from 1 to 2 minutes.

It looks promising. It might be ready for testers shortly.

Have run the fuzzer unit test simultaneously in sys-whonix and five anon-vm.

THAT is bombarding, but sdwdate-gui-qubes is still alive, after a few runs...

What happens in case of multiple Whonix-Gateway ProxyVMs? I.e. in case of sys-whonix, sys-whonix-two, etc.? How would anon-whonix-two know it has to connect to sys-whonix-two?

@marmarek asked:

I assume those VMs will locate each other some other mechanism, so anon-whonix will know to call to appropriate whonix gateway, even if user create custom one, right?

Can you think of any mechanism suitable for that?

For the time being, the vm's whonix gateway is hard coded in two files, the one watching and sending sdwdate satus and the one sending the shutdown notification.

The easiest way would be to have a new entry for qubesdb-read, in addition to qubes-gateway which holds the IP address.
Something like qubesdb-read /qubes-gateway-name.

In T534#16397, @troubadour wrote:

The easiest way would be to have a new entry for qubesdb-read, in addition to qubes-gateway which holds the IP address.
Something like qubesdb-read /qubes-gateway-name.

I'm ok with that, unless you consider it a privacy issue.

Created way to find out name of gateway from witin VM - qubesdb-read /qubes-gateway-name for it.