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


I don’t know how long it will take to get it fixed so here is the workaround:

On the second thought we should be careful with this. If not absolutely
required for Whonix 14, leaving it out. This could introduce some unique

First of all, we have to see what upstream thinks about this and how
they go about fixing it. Then if possible and needed, we can add their
fix in Whonix earlier than their fix flows down to Whonix.

1 Like

I agree. It seems only anon-connection-wizard and swdate is using systemd to start Tor so it is not a big problem I guess:

user@host:~/Whonix/packages$ mygrep -r -i "systemctl.*restart tor"
sdwdate/usr/lib/sdwdate/suspend-post:      systemctl --no-pager restart tor@default
anon-connection-wizard/usr/lib/python3/dist-packages/anon_connection_wizard/tor_status.py:    command = 'systemctl --no-pager restart tor@default
1 Like


1 Like
1 Like

Great catch!

Thank you so much, Patrick!

1 Like

From Whonix VirtualBox - Testers Wanted! - #15 by TechieMike

Any idea what might cause calling kdesudo without any arguments?

Tried to safeguard against it, but not sure I managed.




1 Like
user@host:~/Whonix$ mygrep -r -i "command = 'kdesudo"
packages/whonix-repository/usr/lib/whonix-repository/whonix-repository-wizard:    command = 'kdesudo %s' % (whonix_repository_wizard)
packages/anon-connection-wizard/usr/lib/anon-connection-wizard/anon-connection-wizard:    command = 'kdesudo {}'.format(anon_connection_wizard)
packages/whonix-setup-wizard/usr/lib/whonix-setup-wizard/whonixsetup_check_for_start:   command = 'kdesudo {} setup'.format(whonix_setup_wizard)
packages/whonix-setup-wizard/usr/lib/whonix-setup-wizard/whonix-setup-wizard-setup:command = 'kdesudo {} setup'.format(whonix_setup_wizard)

I guess the only possible commands cause this problem are these two:

packages/whonix-repository/usr/lib/whonix-repository/whonix-repository-wizard:    command = 'kdesudo %s' % (whonix_repository_wizard)
packages/anon-connection-wizard/usr/lib/anon-connection-wizard/anon-connection-wizard:    command = 'kdesudo {}'.format(anon_connection_wizard)

My guess is variables whonix_repository_wizard and/or anon_connection_wizard are not referenced, making the kdesudo called without arguments.

When seeing the code:

whonix_repository_wizard = distutils.spawn.find_executable("whonix-repository-wizard")
if not whonix_repository_wizard == "":
    command = 'kdesudo {}'.format(whonix_repository_wizard)
    call(command, shell=True)

distutils.spawn.find_executable will return None when executable not found; however, None != "".

distutils.spawn.find_executable should be replaced by shutil.which anyway since the former one is not well-documented and widely used.

I will do some pull requests to fix it.

1 Like


1 Like


1 Like



Merged. :slight_smile:

1 Like

So no more distutils.spawn.find_executable in Whonix code anywhere? :slight_smile:

1 Like

Merged. :slight_smile:

1 Like

By the way, I think it would be unreasonable to ask you to do github
pull requests. Not asking for that from anyone else currently either.
Usually it should be enough if you do the git commits. Then I just git
fetch your repository and merge.

Otherwise the more formal approach for third party projects is to create
a new branch based on the source branch (mostly master, some call it
stable or something else), and then create a pull request. Since we’re
familiar here, we can skip such formalities to save time.

On the other hand, github pull requests leave a nice history on github.
So it’s up to you.

(Maybe if we introduce a Whonix14 branch or so or call master only for
Whonix14 or something… Then it may be reasonable to work with
branches. But for now we can keep it simple.)

1 Like

Minor fix.


1 Like

Not anymore after these two PRs:


1 Like

Sounds good to me. :slight_smile: Feel free to do the git pull irykoon master if it is more convenient for you.

Sometimes, I need to inform you I did some commits on a repository anyway, so in some cases, I may still use a pull request as a notification that is harder to be missed in the future.

No worry about this. The nice history will neither increase nor decrease my contributions to Whonix. :slight_smile:

1 Like

That’s why I did anyhow. Already. Even less reason to ask you open a github pull request.

Somehow I need to learn about new commits.


1 Like

It seems the bug will not be fixed very soon by the upstream and I have been using this workaround for a while without any problem.

Do you think it is a good idea to merge it? If not, I can git rm it.

1 Like

The case that bug will be met if we do not add this workaround may be more common than we previously think:

People restart the Tor with DisableNetwork 1, then they want to use arm which will not be opened since the control port is not opened.

1 Like

The way tor_status.py check DisableNetwork and enable/disable Tor is out of date:

The better way to do this is using Tor controller:

Since this will be an almost complete rewrite of tor_status.py, I will think more about this and implement and test it with cautious.

Current thought:

  1. If Tor process is not enabled, do systemctl --no-pager restart tor@default (In Whonix, Tor process should always be up and the only difference is connected to the Tor network or not. Correct?)
  2. Enable/Disable Tor through Tor control port
  3. Control if Tor will auto connecting to the Tor network at next boot by writing DisbaleNetwork 1 in the files.
  4. I guess we should pop up anon-connection-wizard at boot time as long as Tor is not connecting to the Tor network? (This is not the case currently, btw. And yes, I will fix it if it is not the expected behavious. )