[graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion

Development
61

You will have to merge before you can test in Whonix-Gateway. Your repositories are several commits behind.

I don't know about the Help button usability and unfortunately Jason is not available at the moment. Not a big deal. If it's functional and robust, we could use that for Whonix 10 already.
Not quite finished. For example, the finish page texts in case of big problem like bad or missing torrc are written, but should be reviewed, as much for syntax as technical relevance.

For the contextual help, your suggestion below was very helpful, it opens possibilities. I can finish writing the help, and Jason review it later, but I’ll have questions. The first one: why would we want to disable Tor networking? I’ll have to explain (at the moment, it is “in case of blah, blah…”, not very enlighting).

Would it be hard to make more like a info symbol one can hover over by mouse?
No, pretty simple, I should have thought about it. No info symbol (yet), but when the user hovers the mouse over an option, a popup tool tip is displayed. Pretty and flexible. Implemented in [url=https://github.com/troubadoour/whonix-setup-wizard/commit/bf58535230645688782d2fa06ae56fbba996c945]removed Help button, added mouse hover popups (tooltips). [/url]. Another bonus is that it cleans the code in the wizard main logic function, which is already complex enough without the conditions for showing or not the help button. Cleaner code, better code.
62
Not quite finished.
Yeah. Small misunderstanding. Was only referring to the help button only.

[hr]

Previously I tested your ~14 hours old changes. Just didn’t push yet.

Reviewed your new changes.

[hr]

The tool tips look good. Would it be hard to make the text of the tooltip copyable? I guess some will want to copy and paste it to the forums to discuss/ask.

[hr]

The texts for the tool tips, yeah, they’re not that useful yet. This is more like a usability than code question obviously. So it might help if I explain a bit the background why Tor comes disabled by default at all. Please see:

In past, when Tor was automatically connecting, it was difficult for bridge users to avoid contact to the public Tor network. So it now comes disabled by default. But to keep it easy for others to let it connect, whonixsetup was created that explains a bit the various situations and options.

Why disable it… Good question. Well, if there is an option to enable Tor, it would be illogical if there was no option to disable Tor. Also it’s the option that users would choose, that want to set up bridges/VPN/etc. first. Otherwise they could just press the cancel button. The disabling feature given them a better feeling since it also does some sanity checking. After configuring Whonix, it might indeed not make that much sense to fire up whonixsetup again and disable Tor. However, a few might befit from this. For example if they travel and use Tor in various different places. Sometimes with/without bridges, sometimes with different bridges etc.

The current tooltip for enable Tor shouldn’t tell to go through disable Tor, but to go through the “Tor is censored in my area” one. Then perhaps use the same text that whonixsetup uses. That one we can adjust. I wouldn’t know what a tooltip for “Tor is censored in my area” could say. Perhaps a symbol and only tooltips where they are useful.

Hope that helps us to cook something up that can cope up with the current state of development.

[hr]

What we also need is an autostart mechanism that starts whonixsetup when required. For whonixsetup, currently implemented here:

I think there is no reason to re-implement that startup check in python. Although we are going to start a python gui application, that script would be greatly simplified. (No need to: wait; maximize window; show motd) You could leave that to whonixsetup / me if you wish.

Most importantly, instead of

sudo whonixsetup --x

it would just run.

su-to-root -X -c whonix-setup-wizard

And we need an /etc/sudoers.d/whonix-setup-wizard exception to make this possible without entering password (that would be very confusing to new users). [Easy, just look at whonixsetup /etc/sudoers.d/whonixsetup and adapt the file name.]

Or we move these files into whonix-setup-wizard. Then we’d need to figure out how to tell setup.py how to install them to the proper places.

63

Would you mind if I reverted the setup.py packaging method back to the old generic packaging method some day?

Now that I saw how setup.py creates Debian packages, it wouldn’t be hard to install the files in the same locations and running the preinst/postinst/prerm/postrm the same way setup.py would have set up.

File paths would change, but otherwise no changes from your side would be required.

64

[quote=“Patrick, post:63, topic:650”]Would you mind if I reverted the setup.py packaging method back to the old generic packaging method some day?

Now that I saw how setup.py creates Debian packages, it wouldn’t be hard to install the files in the same locations and running the preinst/postinst/prerm/postrm the same way setup.py would have set up.

File paths would change, but otherwise no changes from your side would be required.[/quote]
I would not mind as long the files are installed in a proper python path. That would actually be better, as we would have a consistent build process through all the packages.

I have pushed a couple of cosmetic commits in whonix-reopository-wizard and whonix-setup-wizard. Please merge as I will have to get your branch again after a complete and difficult upgrade of my whole system. Amongst other problems, VirtualBox installation was quite temperamental in jessie, and I cannot even post anything in the support forum, as I really do not understand how I got it working.

n past, when Tor was automatically connecting, it was difficult for bridge users to avoid contact to the public Tor network. So it now comes disabled by default. But to keep it easy for others to let it connect, whonixsetup was created that explains a bit the various situations and options.

Why disable it… Good question. Well, if there is an option to enable Tor, it would be illogical if there was no option to disable Tor. Also it’s the option that users would choose, that want to set up bridges/VPN/etc. first. Otherwise they could just press the cancel button. The disabling feature given them a better feeling since it also does some sanity checking. After configuring Whonix, it might indeed not make that much sense to fire up whonixsetup again and disable Tor. However, a few might befit from this. For example if they travel and use Tor in various different places. Sometimes with/without bridges, sometimes with different bridges etc.


OK. I could use that and another quotes from the wiki/forums to put together a better help in the tooltips.

I have not looked into the auto-start mechanism yet, but that should be relatively easy. I’d like to discuss the next development step first.

As I see it, we have three options for the bridges:

1- we mimic whonixsetup connection wizard, with a pure text approach, no actions.

2- we install TBB with tb-updater and use tor-launcher with the modified Tails bash script. I could not get it working properly, have to give it another try. To use it safely in our case (Whonix-Gateway), that would suppose some code rewriting and I do not not speak javascript. It is probably in my reach to get a minimal understanding in order to modify the scripts but that would take time. Let say that we fork and modify tor-launcher, how do we deal with the updates from the Tor project?

3- we give our own options and modify /etc/tor/torrc accordingly. I made some manual tests (not wit the wizard, but that would be feasible). /etc/tor/torrc could look like that, with some of the currently available pluggable transports:

# This file is part of Whonix
# Copyright (C) 2012 - 2013 adrelanos <adrelanos at riseup dot net>
# See the file COPYING for copying conditions.

# Use this file for your user customizations.
# Please see /etc/tor/torrc.examples for help, options, comments etc.

# Anything here will override Whonix's own Tor config customizations in
# /usr/share/tor/tor-service-defaults-torrc

# Enable Tor through whonixsetup or manually uncomment "DisableNetwork 0" by
# removing the # in front of it.
DisableNetwork 0

#UseBridges 1

#Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9
#Bridge obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239
#Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9
#Bridge obfs3 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A
#Bridge obfs3 109.105.109.163:38980 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED
#ClientTransportPlugin obfs3 exec /usr/bin/obfsproxy managed

#Bridge scramblesuit 188.226.213.208:54278 AA5A86C1490296EF4FACA946CC5A182FCD1C5B1E password=MD2VRP7WXAMSG7MKIGMHI4CB4BMSNO7T
#Bridge scramblesuit 83.212.101.3:443 A09D536DD1752D542E1FBB3C9CE4449D51298239 password=XTCXLG2JAMJKZW2POLBAOWOQETQSMASH
#ClientTransportPlugin scramblesuit exec /usr/bin/obfsproxy managed

#Bridge meek 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com
#Bridge meek 0.0.2.0:2 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com
#Bridge meek 0.0.2.0:3 url=https://az668014.vo.msecnd.net/ front=ajax.aspnetcdn.comments
#ClientTransportPlugin meek exec /usr/bin/meek-client --log meek-client.log

After the user choice, it would be a matter of uncommenting the lines required by the transport.

Note: scramblesuit and obfs3 are working. I could [edit] NOT get a connection with meek (either service) after installing meek-client from https://git.torproject.org/pluggable-transports/meek.git (requires golang-go for building, see meek ¡ Wiki ¡ Legacy / Trac ¡ GitLab).

As you mentioned earlier, that solution would probably demand some maintenance. I do know if it would be more than option 2, but it would be Python only, until we have a fluent js coder. Anyhow, we could try implementing both… and see which one is the easiest, and most usable.

65
I have pushed a couple of cosmetic commits in whonix-reopository-wizard and whonix-setup-wizard. Please merge
Done. :)
as I will have to get your branch again
Maybe some misunderstanding at work here. Git is fully distributed. It shouldn't matter where you clone a repository from.
As I see it, we have three options for the bridges:

1- we mimic whonixsetup connection wizard, with a pure text approach, no actions.


Looks best and simplest as a short time solution.

2- we install TBB with tb-updater and use tor-launcher with the modified Tails bash script. I could not get it working properly, have to give it another try. To use it safely in our case (Whonix-Gateway), that would suppose some code rewriting and I do not not speak javascript. It is probably in my reach to get a minimal understanding in order to modify the scripts but that would take time. Let say that we fork and modify tor-launcher, how do we deal with the updates from the Tor project?
Yes, updates would be an issue. But running tor-launcher standalone using xulrunner or so does not look so attractive to me anyhow. Because then you still have to download meek from some third party git repository. Looks like Tails somehow modified it, so it only supports obfuscated bridges, no support for meek and so forth.
3- we give our own options and modify /etc/tor/torrc accordingly. I made some manual tests (not wit the wizard, but that would be feasible). /etc/tor/torrc could look like that, with some of the currently available pluggable transports:

After the user choice, it would be a matter of uncommenting the lines required by the transport.


That works for obfsproxy transports, but not so much for meek and others. Because those won’t likely be packaged for Debian anytime soon. And pluggable transports are too fast moving targets. Would be hard to do the packaging @Whonix project and keeping up with them.

That’s why I came up with the idea use “Tor, tor-launcher, pluggable transports from TBB package as system Tor on Whonix-Gateway”. It comes with all the pluggable transports such as meek etc. Much better than just tor-launcher as standalone xulrunner app.

As you mentioned earlier, that solution would probably demand some maintenance. I do know if it would be more than option 2, but it would be Python only, until we have a fluent js coder. Anyhow, we could try implementing both... and see which one is the easiest, and most usable.
I posted on sourceforge help wanted forum: https://sourceforge.net/p/forge/helpwanted/programmers/thread/96496d0a/

The first one who answered probably was overwhelmed or not interested in the tor-launcher task and didn’t reply. But someone else contacted me. He’s currently trying Whonix and might help with this javascript task. Just now asked him if he could reply to this thread.

66

Hi there,

I’m the one that didn’t get overwhelmed :smiley:

Just doing the normal updates etc at the moment, but I’m really looking forward to getting into the nuts and bolts of all this so I can make some headway in this issue for you all :slight_smile:

I’m hanging out in IRC and can be contacted there or via PM here.

Looking forward to working with you all!

67

Hi crackman,
welcome, thanks for signing up here! Let’s use forum messages or IRC. PM (as in forum private messages) is non-ideal and disabled for some time now due to legal issues resulting from it.

68

@troubadour: Looks like changing python-guimessages back to generic packaging method rather than setup.py is even simpler than anticipated. The main change would be.

[font=courier]debian/rules[/font]

	dh $@ --with python2

(Wouldn’t have found out that so easily without looking at what [font=courier]debianize[/font] is doing.)

Produced an experimental git branch:
https://github.com/Whonix/python-guimessages/tree/generic_packaging

Here is the debdiff:

~/compare $ debdiff pymethod/python-guimessages_*.deb gpmethod/python-guimessages_*deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r--  root/root   /usr/share/doc/python-guimessages/copyright

Files in first .deb but not in second
-------------------------------------
-rw-r--r--  root/root   /usr/share/pyshared/guimessages-0.0.6.egg-info
lrwxrwxrwx  root/root   /usr/lib/python2.7/dist-packages/guimessages-0.0.6.egg-info -> ../../../share/pyshared/guimessages-0.0.6.egg-info

Control files: lines which differ (wdiff format)
------------------------------------------------
Description: [-Python translation utilities-] {+Translatable GUI Messages+}
{+ Generic modules guimessage.py and translations.py.+}
{+ Called with two parameters: .yaml file path and yaml section. Return+}
{+ translations according to distribution local language (Python 'locale').+}
{+Homepage: https://www.whonix.org/+}
Maintainer: [-troubadoour-] {+troubadour+} <trobador@riseup.net>
[-Source: guimessages-]
Version: [-0.0.6-1-] {+3:0.2-1+}

No lintian warnings.

So the only notable change would be the missing file [font=courier]/usr/share/pyshared/guimessages-0.0.6.egg-info[/font]. Unless there is some argument we need that egg-info file for something, I’ll do more testing, clean up and finish this branch anytime soon.

69
So the only notable change would be the missing file /usr/share/pyshared/guimessages-0.0.6.egg-info. Unless there is some argument we need that egg-info file for something, I'll do more testing, clean up and finish this branch anytime soon.
No argument against removing egg-info. As far as I understand, it is mostly useful in the case we want to use different versions of the same package in the same installation. That should not concern Whonix.
What we also need is an autostart mechanism that starts whonixsetup when required. For whonixsetup, currently implemented here: - https://github.com/Whonix/whonixsetup/blob/master/etc/xdg/autostart/whonixsetup.desktop - always autostarts in X, desktop environment agnostic - https://github.com/Whonix/whonixsetup/blob/master/usr/lib/whonixsetup - checks conditions whether or not to start whonixsetup

I think there is no reason to re-implement that startup check in python. Although we are going to start a python gui application, that script would be greatly simplified. (No need to: wait; maximize window; show motd) You could leave that to whonixsetup / me if you wish.


I think it is better if you make the simplifications in /usr/lib/whonixsetup, and the change to etc/xdg/autostart/whonixsetup.desktop.

A small issue: when the user runs Whonix-Gateway for the fist time, gateway_first_run_notice will pop together with whonix-setup-wizard. It would be worth for user-friendliness to look into that (I can do it).

Regarding the help in the wizard, could we leave it as is for the moment (with some small changes though, the ‘I want to disable Tor’ is one), waiting for outcome of [Tor tor-launcher pluggable transports], and leave the options disabled.

Pushed a commit to whonix-setup-wizard check whonix-repository-wizard exists. ¡ troubadoour/whonix-setup-wizard@308e3ab ¡ GitHub (check if whonix-repository-wizard exists, new page if not. Feel free to modify the text in whoni-setup.yaml).

70

Okay.

Yeah. I could imagine this interaction could become quite difficult?

What I also noticed, starting the whonix-repository-wizard from whonix-repository-setup also looks somewhat confusing. Do you think those could be embedded without too much going nuts?

Regarding the help in the wizard, could we leave it as is for the moment (with some small changes though, the 'I want to disable Tor' is one), waiting for outcome of [Tor tor-launcher pluggable transports], and leave the options disabled.
It could be a while until the tor-launcher stuff has been sorted out. We'd need to wait for patches being merged upstream anyhow. So for Whonix 10 it would be nice if it was as good as whonixsetup. For long term, we'll see about tor-launcher.
71

For reference only. Debdiff with generic packaging method for whonix-repository-wizard looks sane as well.

~/compare/whonix-repository-wizard $ debdiff pymethod/*.deb gpmethod/*.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r--  root/root   /usr/share/doc/whonix-repository-wizard/copyright
-rw-r--r--  root/root   /usr/share/man/man1/whonix-repository-wizard.1.gz

Files in first .deb but not in second
-------------------------------------
-rw-r--r--  root/root   /usr/share/pyshared/whonix_repository_wizard-1.0.egg-info
lrwxrwxrwx  root/root   /usr/lib/python2.7/dist-packages/whonix_repository_wizard-1.0.egg-info -> ../../../share/pyshared/whonix_repository_wizard-1.0.egg-info

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: {+whonix-repository, menu,+} python (>= 2.7), python (<< 2.8), python-yaml, python-guimessages
Description: [-Wizard running whonix_repository-] {+GUI Whonix APT Repository Tool+}
{+ This tool can always be used to enable either Whonix's stable, testers or+}
{+ developers repository or to disable Whonix's repository.+}
{+ .+}
{+ Whonix's APT Repository is not enabled by default. Some users prefer this for+}
{+ trust/security reasons.+}
{+ .+}
{+ On first boot of Whonix, the Whonix Repository Tool gets automatically started+}
{+ by whonixsetup. The user is free to either leave Whonix's repository disabled+}
{+ or to configure it as desired.+}
{+ .+}
{+ Technically speaking, this tool creates or deletes+}
{+ /etc/sources.list.d/whonix.list and adds or deletes Whonix's signing key from+}
{+ apt-key.+}
{+Homepage: https://www.whonix.org/+}
Installed-Size: [-72-] {+81+}
Maintainer: [-troubadoour-] {+troubadour+} <trobador@riseup.net>
{+Recommends: anon-icon-pack+}
Section: [-python-] {+misc+}
Version: [-1.0-1-] {+3:0.2-1+}

Debdiff whonix-setup-wizard and git commits to git master coming soon.

72 
~/compare/whonix-setup-wizard $ debdiff pymethod/*.deb gpmethod/*.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r--  root/root   /usr/share/doc/whonix-setup-wizard/copyright
-rw-r--r--  root/root   /usr/share/man/man8/whonix-setup-wizard.8.gz

Files in first .deb but not in second
-------------------------------------
-rw-r--r--  root/root   /usr/share/pyshared/whonix_setup_wizard-1.1.egg-info
lrwxrwxrwx  root/root   /usr/lib/python2.7/dist-packages/whonix_setup_wizard-1.1.egg-info -> ../../../share/pyshared/whonix_setup_wizard-1.1.egg-info

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: {+whonixsetup, menu,+} python (>= 2.7), python (<< 2.8), python-yaml, python-guimessages
Description: {+First Time Connection Setup+}
{+ When+} Whonix [-setup wizard-] {+starts for the first time, it won't automatically connect to the+}
{+ public Tor network. This is useful for users who want to hide Tor from their+}
{+ ISP. whonixsetup is automatically started, which educates about different+}
{+ methods to connect (public Tor network, bridges, etc.).+}
{+ .+}
{+ Also automatically starts the Whonix Repository Tool (if installed), so the+}
{+ user can decide whether to use Whonix's Repository and if yes, choose which+}
{+ one.+}
{+Homepage: https://www.whonix.org/+}
Installed-Size: [-92-] {+101+}
Maintainer: [-troubadoour-] {+troubadour+} <trobador@riseup.net>
{+Recommends: anon-icon-pack+}
Section: [-python-] {+misc+}
Version: [-1.1-1-] {+3:0.2-1+}

[hr]

Should we ever need the egg metadata file for some reason let’s not revert to setup.py. That file isn’t magic and if all cords break we can manually create it or figure out some debian tool to do that for us. The current debhelper python2 method is apparently a common and robust way to package python stuff for Debian.

73

Done:
all three packages reverted to generic packaging method. apt-get purgeed them beforehand. Then make deb-icuped and tested them. Seems to work all fine. Please merge.

74

Here is the relevant changelog:

whonixsetup: in x, prefer starting the graphical version whonix-setup-wizard, fall back to cli version whonixsetup when graphical version is not available

whonixsetup: removed start menu entry and startup script for cli version whonixsetup because x version whonix-setup-wizard will add its own

whonix-repository-wizard: added sudoers exception file etc/sudoers.d/whonix-setup-wizard for allowing to start whonix-setup-wizard as root without password for better usability when autostarting it

(+ some refactoring of whonixsetup auto startup script)

[hr]

One issue I am struggling with now. Two assumptions. We want to autostart whonix-setup-wizard on first run, yes? And not ask for a password, because that would be confusing to new users, yes? Unfortunately I haven’t found a gui tool yet that obeys [font=courier]/etc/sudoers.d/[/font] settings folder.

Currently using

su-to-root -X -c whonix-setup-wizard

which in kde default to use

/usr/lib/kde4/libexec/kdesu -u root whonix-setup-wizard

But kdesu does not support sudoers settings.

Now, we could make su-to-root use a specific tool such as kdesudo or gksudo. (Using settings file or environment variable.)

Any idea for any su-to-root-like tool, that supports exceptions to make certain commands run passwordless? Perhaps I should ask on stackexchange.

75

Merged the changes in packaging. Works fine. :slight_smile:

[quote]Regarding the help in the wizard, could we leave it as is for the moment (with some small changes though, the 'I want to disable Tor' is one), waiting for outcome of [Tor tor-launcher pluggable transports], and leave the options disabled. [/quote] It could be a while until the tor-launcher stuff has been sorted out. We'd need to wait for patches being merged upstream anyhow. So for Whonix 10 it would be nice if it was as good as whonixsetup. For long term, we'll see about tor-launcher.
Pushed two commits. The last one is [url=https://github.com/troubadoour/whonix-setup-wizard/commit/63160c86c9c705435562363a21066447b0d31dcf]last tooltips… [/url] Had to find a workaround the text only options (no next page, so disable Next button when selected).
What I also noticed, starting the whonix-repository-wizard from whonix-repository-setup also looks somewhat confusing. Do you think those could be embedded without too much going nuts?
Should be feasible. Will try embeding whonix-repository-wizard in Whonix Setup (single wizard). The script will be longer, but still readable, hopefully (some more if's...). We will need a parameter to run whonix-setup-wizard in "Whonix Repository only" mode.

Before getting into the su-to-root issue, a remark. Running a GUI with su-to-root vs kdesudo (or gksu too, I guess) makes a big difference: the graphic output is not the same. kdesudo seems to revert to an older look (before PyQt4 probably), and the layout is different. At the beginning of the development, I was using kdesudo, and I had to change the size of the disclaimer pages when I first built a merged package with su-to-root. No idea why, but so far, I could not find much literature on stackexchange, be it on su-to-root or the menu package.

76

whonix-setup-wizard: Merged. Edited output a bit. There is one small bug. If you press back, then the two locked options are unlocked.

whonix-repository-wizard: There is one thing that is a bit confusing. If you click “next” for the first time, mouse is at position of the “next” button. You then don’t move the mouse and press “next” again. But in the last and third screen, at the position where the “next” button was is now the “back” button. Wondering, if this should be improved and how? What about “back | finish | cancel”, while the “cancel” button is deactivated for the last screen?

su-to-root is just a bash wrapper script that chooses kdesu, kdesudo, gksu etc. depending on what is installed. So if we find any suitable replacement tool, we can use that.

77

Is there a graphical sudo (kdesudo, gksudo, su-to-root, …) tool that works passwordless?:

78

I use a kdesu shortcut on my desktop in order to run Dolphin as root. The steps to create such a shortcut are:

Right-click on your desktop.
Create new.
Link to application.
Application tab.
In the command box, type (using your own path):

kdesu -u root dolphin /path/to/your/folder

When you run it the first time you will be prompted for the password but there is a checkbox to remember the password.

79

We want to use it without asking for password at all. Because it would be confusing if on first boot there would be an enter your password box.

80

Use a shell script:

#!/bin/bash # Run Dolphin as root in some folder. # # Allow user "root" access to the X server. xhost +local:root # # The -S switch is to accept standard input: echo "password" | sudo -S dolphin /path/to/folder