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

Development
81

Yeah. That works. Thanks, Dennis!

Commit:
https://github.com/Whonix/whonixsetup/commit/6be9f1e25cb1a606f6dee9133b9c69b8d5b3d278

@troubadour:
Pushed commits to whonix-setup-wizard as well as whonix-repository-wizard. The sudo/root issue should now be sorted out. Since whonix-setup-wizard will be already root, there is no reason for whonix-setup-wizard to run whonix-repository-wizard using “sudo”.

82

Great! One more step toward usability.

whonix-setup-wizard: Merged. Edited output a bit. There is one small bug. If you press back, then the two locked options are unlocked.
Fixed in [url=https://github.com/troubadoour/whonix-setup-wizard/commit/26e0ab07e242b14c9de82c438750528e4826db50]26e0ab07[/url].
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?
Done in [url=https://github.com/troubadoour/whonix-repository-wizard/commit/ec328fe2d4ea8bae70007170abb96207f62ed245]ec328fe2[/url].
83
[quote]whonix-setup-wizard: Merged. Edited output a bit. There is one small bug. If you press back, then the two locked options are unlocked.[/quote] Fixed in [url=https://github.com/troubadoour/whonix-setup-wizard/commit/26e0ab07e242b14c9de82c438750528e4826db50]26e0ab07[/url].
It contained some unrelated changes (reverted my textual changes), but nevermind, fixed it in git master.
[quote]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?[/quote] Done in [url=https://github.com/troubadoour/whonix-repository-wizard/commit/ec328fe2d4ea8bae70007170abb96207f62ed245]ec328fe2[/url].
Awesome! Much more intuitive now. I guess this change will spare us a few bug reports.

[hr]

Current sequence if /var/lib/whonix/do_once/whonixsetup.done does not exist…

Something is wrong with torrc! Press "Next" and try and fix the problem as per the instructions, or as a last resort, report a bug.
First boot! Whonix Setup will run Whonix Repository Wizard. Click "Next" to start the wizard and finish Whonix Setup.
cannot_connect

I think 2. and 3. should be swapped. If one page says next page will contain the error message, next page really should contain it.

[hr]

One thing is indeed hard. For technical reasons, Whonix Repository Wizard should indeed always be started before starting whonixcheck - because depending on whether Whonix’s repository has been enabled or not, whonixcheck will report different stuff. (repo enabled yes/no info msg + maybe different versions of updateable packages)

I am wondering if starting Whonix Repository Wizard from Whonix Setup Wizard is a good way anyhow. Most likely it cannot be embedded as normal pages? Or at least that would be difficult? But anyhow. I am wondering if the script that starts Whonix Setup Wizard (whonixsetup: /usr/lib/whonixsetup_x_start_maybe) wouldn’t be a better place to start all the gui’s? One after another? /usr/lib/whonixsetup_x_start_maybe could first start Whonix Repository Tool (depending on if it has been run beforehand, using a .done file) and after it exited, it could start Whonix Setup Wizard. Perhaps that would prevent overlapping windows, code complexity and confusion? In extension, it should maybe also start whonix-gw-first-run-notice? And perhaps whonixcheck at the end conditionally depending on Whonix Setup Wizard? Just thinking…

If we go that route however, whonix-gw-first-run-notice and Whonix Repository Wizard should say something like “please at least close this, so other one time first boot wizards can be started” or so.

84
I think 2. and 3. should be swapped. If one page says next page will contain the error message, next page really should contain it.
Something I overlooked. Will be fixed (and do no run whonixcheck if fail to read or write torrc, obviously).
One thing is indeed hard. For technical reasons, Whonix Repository Wizard should indeed always be started before starting whonixcheck - because depending on whether Whonix's repository has been enabled or not, whonixcheck will report different stuff. (repo enabled yes/no info msg + maybe different versions of updateable packages)

I am wondering if starting Whonix Repository Wizard from Whonix Setup Wizard is a good way anyhow. Most likely it cannot be embedded as normal pages? Or at least that would be difficult?


Actually, it does not seem that difficult. All in all, I believe that having a single Whonix setup wizard would be would be beneficial, both to the user and the design (the design flow is there, I have started with the code. It makes the script longer, but the logic does not change).

Pro:

  • simpler bash script, run whonix-setup-wizard, that’s it. whonixsetup.done for whonixrepository is taken care of by the wizard.
  • No change in the structure either (like the bash option). /usr/bin/whonix-repository-wizard runs whonix-setup-wizard with a parameter.

Con: some extra logic in the wizard, to run whonix repository pages only. No that a big deal, with good comments, the code should still be readable by an outsider with python skills.

Now, whonix-gw-first-run-notice is another story, but it would probably be more logical to run it before the setup wizard. The problem is that the user has the choice to run it again at next boot, and some script has to check first_use_check.done and may be another .done file for Whonix setup (Whonix repository .done is checked in the wizard). As far as I understand, whonixsetup is auto-started only if Tor in not enabled, and most likely, we should keep that too.

85

whonix-repository-wizard is embedded in whonix-setup-wizard in cdaf1de3. It works except for su-to-root, which apparently does not accept arguments. Looking into that.

For testing, run:

kdesudo whonix-setup-wizard setup
kdesudo whonix-setup-wizard repository
86

Pushed some small changes. af935e4c

87

Sorry, no need to look, the problem was fixed in https://github.com/Whonix/whonixsetup/commit/6be9f1e25cb1a606f6dee9133b9c69b8d5b3d278. Tested OK. Will only need a maybe-start script for whonixrepository.

88

Very nice!

When running

kdesudo whonix-setup-wizard repository

the output of exit code of whonix_repository is no longer shown.

Somehow my textual changes from a while ago are getting overridden (as last time):

89

[quote=“Patrick, post:88, topic:650”]When running

kdesudo whonix-setup-wizard repository

the output of exit code of whonix_repository is no longer shown.[/quote]
Re-implemented. 50708935

Somehow my textual changes from a while ago are getting overridden (as last time): - https://github.com/Whonix/whonix-setup-wizard/commit/cdaf1de3228b38a2a04d968c81f4311b18bab716#diff-304898f0e0d8b9f3c289421468cbd052L166 - https://github.com/Whonix/whonix-setup-wizard/commit/cdaf1de3228b38a2a04d968c81f4311b18bab716#diff-304898f0e0d8b9f3c289421468cbd052L185
Don't know why. I fetched and merged each time. This time, I have deleted my local repository, cloned again, but I cannot see those changes.
90

Pushed a couple if fixes in whonix-setup-wizard, for Whonix Workstation.

91

A big commit. 37d72437

  • modifies /etc/xdg/autostart/whonixsetup.desktop, now running:
  • new python script whonixsetup_check_for_start, which runs /usr/lib/gateway_first_run_notice prior to deciding wether or not run whonix setup, X or cli.
  • modifies /usr/share/applications/whonix_setup.desktop (kdesudo, su-to-root does not handle arguments).

In 767b15ca:

  • changes to tor_status.py because of an issue when Whonix Setup is auto-started (see comments in the script).

If this approach looks sound, there are some error managements left to be implemented.

92
Don't know why. I fetched and merged each time. This time, I have deleted my local repository, cloned again, but I cannot see those changes.
I think this could be the behavior of a text editor.

Either,

  • before running “git add *”, please run “git diff”,
  • or, after running “git add *”, please run “git diff --cached”.
    Set up a graphical diff viewer. That will show what you’re actually going to commit. Then it will be almost impossible to accidentally revert files to a later state.

From integration of gateway_first_run_notice in Whonix Setup. · troubadoour/whonix-setup-wizard@37d7243 · GitHub this also looks like an accident.

-Exec=su-to-root -X -c whonix-setup-wizard
+Exec=kdesudo whonix-setup-wizard setup

Can you undo them please?

93

Unless there is a reason for “su-to-root -X -c” vs “kdesudo”?

94

[quote=“Patrick, post:92, topic:650”]Either,

  • before running “git add *”, please run “git diff”,
  • or, after running “git add *”, please run “git diff --cached”.
    Set up a graphical diff viewer. That will show what you’re actually going to commit. Then it will be almost impossible to accidentally revert files to a later state.[/quote]
    I do run “git diff --cached” and have “/bin/git-meld” with the proper settings in ~/.gitconfig, so that meld is diffing all the changes in the package (I could not work without it now). Apparently, something happened after I reverted a commit to merge you changes before re-commiting and pushing. May be a mistake…
From https://github.com/troubadoour/whonix-setup-wizard/commit/37d7243746b4ebb3f368c03c4b1864efeacd472c#diff-f23866372671239e234a4c52e9e31e28L5 this also looks like an accident. [code] -Exec=su-to-root -X -c whonix-setup-wizard +Exec=kdesudo whonix-setup-wizard setup [/code]

Can you undo them please?


It is not an accident. su-to-root does not work with arguments (“setup” or “repository”). I have not searched for the cause (played it lazily there).

Pushed some commits.

  • open external links for whonix-repository-wizard page 1.
  • in whonix-setup-wizard, removed etc/xdg/autostart/whonixsetup.desktop
  • in whonixsetup, added the modified etc/xdg/autostart/whonixsetup.desktop

This because, when installing the wizard, make deb-icup stops and complains that the file is already installed by whonixsetup.

95

When running “kdesudo whonix-setup-wizard” can you make it default to “setup” please? Because some users might run it from terminal that way.

Hm. su-to-root indeed doesn’t support arguments. Checked its source. But depending on kdesudo isn’t a very clean way. Would make ports or custom builds for other desktop environments harder. Let’s use a wrapper script instead?

This because, when installing the wizard, make deb-icup stops and complains that the file is already installed by whonixsetup.
This is a feature by debian packaging. In such cases, we could 1) remove the file from old package 2) bump debian version number ("make deb-chl-bumpup") before release 3) add file to new package 4) bump up new package as well. Then files can be migrated from one package to another. But using a different name indeed makes packaging conflicts less likely. If it doesn't require changing lots of other files, we can do this.
96

Fixed output again:
https://github.com/Whonix/whonix-setup-wizard/commit/8bd5686422df8fd23ba5aa2861991aa04051a2a8

97

[quote=“troubadour, post:91, topic:650”]A big commit. 37d72437

  • modifies /etc/xdg/autostart/whonixsetup.desktop, now running:
  • new python script whonixsetup_check_for_start, which runs /usr/lib/gateway_first_run_notice prior to deciding wether or not run whonix setup, X or cli.
  • modifies /usr/share/applications/whonix_setup.desktop (kdesudo, su-to-root does not handle arguments).

In 767b15ca:

  • changes to tor_status.py because of an issue when Whonix Setup is auto-started (see comments in the script).

If this approach looks sound, there are some error managements left to be implemented.[/quote]
Yes. Looks sound. I am not sure the “sleep 1” is required. Might have added this only for the look and feel. However, the “sync” in /usr/lib/whonixsetup_/ft_m_1 indicates, I wasn’t sure Tor’s files will really be created in time (which they should).

Please run a “sudo service tor status” at the very end, to make sure it’s really started, because there is indeed a bug in Tor/Tor’s init script as you already noticed by reading in ft_m_1.

When “sudo service tor status”, then /run/tor/control and /run/tor/tor.pid should be guaranteed to be existing. Did you notice they are not? If that’s the case, we should wait some longer for them to be created (can vary a lot on slow systems or hosts with high system load). But let’s not worry about this until this actually happens. Really should not.

98
Yes. Looks sound. I am not sure the "sleep 1" is required. Might have added this only for the look and feel. However, the "sync" in /usr/lib/whonixsetup_/ft_m_1 indicates, I wasn't sure Tor's files will really be created in time (which they should).

Please run a “sudo service tor status” at the very end, to make sure it’s really started, because there is indeed a bug in Tor/Tor’s init script as you already noticed by reading in ft_m_1.


Done in 0b08d11. I left “time.sleep(1)” after “sudo service tor restart”.

When "sudo service tor status", then /run/tor/control and /run/tor/tor.pid should be guaranteed to be existing. Did you notice they are not? If that's the case, we should wait some longer for them to be created (can vary a lot on slow systems or hosts with high system load). But let's not worry about this until this actually happens. Really should not.
Yes, I noticed that the /run/tor/ files were not existing with a normal sequence "start - reload - status". start and reload were exiting normally, but status was reporting "tor is not running ...", because /run/tor/control and /run/tor/tor.pid were not created. But that happens only when the wizard is auto-started, not when it's run by the user. Unexplained for me.

A change in whonixsetup_check_for_start]. Starting the wizard directly, not using whonixsetup_x_start_maybe. This is an extra step which is not required, and we don’t have to move it from whonixsetup to whonix-setup-wizard.

Fixed output again: https://github.com/Whonix/whonix-setup-wizard/commit/8bd5686422df8fd23ba5aa2861991aa04051a2a8
Merged again, same story. It seems that there is a problem with the commit. The diff is shown in the link, but after pressing "View", the changes are not there: https://github.com/Whonix/whonix-setup-wizard/blob/8bd5686422df8fd23ba5aa2861991aa04051a2a8/usr/share/translations/whonix_setup.yaml.
99

[quote=“troubadour, post:98, topic:650”][quote]When “sudo service tor status”, then /run/tor/control and /run/tor/tor.pid should be guaranteed to be existing. Did you notice they are not? If that’s the case, we should wait some longer for them to be created (can vary a lot on slow systems or hosts with high system load). But let’s not worry about this until this actually happens. Really should not.
[/quote]
Yes, I noticed that the /run/tor/ files were not existing with a normal sequence “start - reload - status”. start and reload were exiting normally, but status was reporting “tor is not running …”, because /run/tor/control and /run/tor/tor.pid were not created. But that happens only when the wizard is auto-started, not when it’s run by the user. Unexplained for me. [/quote]
Let me explain the code logic in ft_m_1.

  1. DisableNetwork 0 has been in commented in /etc/tor/torrc. In other words, Tor networking has been enabled.

  2. service tor status : exit code: zero, if running, otherwise non-zero. Reason: check if the Tor daemon is running. In most cases it should be already running. Except in theoretical corner cases, where the user has run “sudo service tor stop” or in hypothetical cases, where the daemon has tied due to a bug in Tor or due to system issues (flawed RAM, bit flip, hdd failure, etc.). I think I added the “sleep 1” for better look and feel and to give advanced users and devs better chance to read the output, to report cases were Tor is not running for some strange reason.

  3. When Tor was running, run “service tor reload”. Theoretically and logically it would makes sense to “service tor reload” rather than “service tor restart”. Reload is faster. Should work. When Tor Tor was not running beforehand, start it using “sudo service tor start”.

  4. service tor status : Due to a bug in Tor/Tor’s init script, Tor might not be running. I assume it died after “reload”.

  5. If it was not started, run “service tor start”. Now Tor should really be running - reload bug or not - or something would be very wrong. Otherwise, if already started, do nothing.

  6. Working around another bug in Tor. When starting Tor fails, it does not return a non-zero return code. Run “service tor status” and check its exit code a final time. When success, continue as usual. When failed, notify the user.

[hr]

Wondering why not just “service tor restart” to avoid all the reload bug?

  • Some day I wanted to be able to actually report this bug or hope it fixes itself over time because someone else succeeds explaining it to TPO.
  • Reload, if it were working, would be faster.
  • Reload is the more appropriate way, I think.
  • Had ports to other linux distributions in mind. Reload might work there.
  • Assume the user though there is some issue with Tor, while Tor is already enabled (DisableNetwork 0). Because it didn’t serve connections yet. In that case by not using restart in all cases I wanted to prevent user’s ISP’s from seeing a connection drop/restart.

[hr]

Maybe it would be best to refactor ft_m_1’s Tor reload/restart/status code to make it standalone, so it can be called from whonix-setup-wizard? Happy to do this. Because that code logic is very old, stable and robust. Re-implementing it in python seems hard getting the same algorithm.

[hr]

[quote=“troubadour, post:98, topic:650”][quote]When “sudo service tor status”, then /run/tor/control and /run/tor/tor.pid should be guaranteed to be existing. Did you notice they are not? If that’s the case, we should wait some longer for them to be created (can vary a lot on slow systems or hosts with high system load). But let’s not worry about this until this actually happens. Really should not.
[/quote]
Yes, I noticed that the /run/tor/ files were not existing with a normal sequence “start - reload - status”. start and reload were exiting normally, but status was reporting “tor is not running …”, because /run/tor/control and /run/tor/tor.pid were not created. But that happens only when the wizard is auto-started, not when it’s run by the user. Unexplained for me. [/quote]
Having explained ft_m_1’s above code logic, my point is: after running “service tor restart” followed by “service tor status”, which exits then the the /run/tor/ files should be guaranteed to be existing. Or have you noticed, they are not?

100

Will come back about tor code logic.

In the meantime, pushed three commits, path and bug fixes.