Jul 25 2019
Jun 27 2019
Jun 24 2019
Apr 14 2019
Dec 7 2018
Nov 20 2018
Sep 27 2018
Aug 23 2018
Aug 7 2018
Jul 25 2018
sclockadj3 is done -> T686.
Jul 21 2018
Created [way to find out name of gateway from witin VM - qubesdb-read /qubes-gateway-name](https://github.com/QubesOS/qubes-issues/issues/4117) for it.
Jul 18 2018
Jul 17 2018
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?
Jul 7 2018
Have run the fuzzer unit test simultaneously in sys-whonix and five anon-vm.
Jul 5 2018
Update, after my post in the forum.
Mar 7 2018
Mar 4 2018
A new Tor controller GUI.
Feb 16 2018
Added the relevant icon in show_message (after resizing the sdwdate icons from mediawiki, the original are huge).
Feb 15 2018
Some progress here.
Feb 4 2018
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
Feb 3 2018
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.
Feb 2 2018
Only small issues for now.
It was actually easier to merge directly, if only for the new user sdwdate-gui created in postint.
Feb 1 2018
sdwdate-gui-qubes will be shortly ready for packaging.
Jan 29 2018
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.
Jan 26 2018
What happens if a workstation is killed, and then later restarted?
Probably no. But I,m not an expert in security or attacks.
Jan 25 2018
The submenu commands are implemented. Looks nice and handy.
Jan 22 2018
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.
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.
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.