I am not sure sdwdate-gui would be a strong enough notification if networking was actually blocked if sdwdate did not succeed yet.

This was implemented. Now using python3 requests.

Good enough.

sclockadj3 is done -> T686.

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

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.

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.

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?

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

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

A new Tor controller GUI.

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

Some progress here.

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

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

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.

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.

Only small issues for now.

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.

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

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.

Relevant code excerpt sdwdate.

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.

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