Sat, Sep 28
Jun 14 2019
Dec 7 2018
Nov 20 2018
Aug 7 2018
Jul 21 2018
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.
Jun 25 2018
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.
Awesome progress! :)
Jan 20 2018
Some progress on this one. A summary without literature.
Jan 16 2018
Playing with tags.
Dec 21 2017
Jul 23 2017
Jul 4 2017
Jul 3 2017
@marmarek is there some qubesdb-read to find out from anon-whonix that its NetVM is sys-whonix?
Jun 12 2017
We have someone working on this now. Some thoughts on the design...
Jun 5 2017
May 26 2017
Note to self: try to disable and see if konsole and kwrite are still functional in timesync-fail-closed mode.