[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

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


#563

#564

iry:

https://github.com/Whonix/whonix-repository/pull/1

Merged. :slight_smile:


#565

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


#566

Merged. :slight_smile:


#567

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.)


#568

Minor fix.


#569

Not anymore after these two PRs:


#570

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:


#571

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.

:slight_smile:


#572

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.


#573

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.


#574

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. )

#575

Actually… Sorry for only getting this into my mind yet… Direct use of systemctl is convenient for us but it may make the package unfit for inclusion into packages.debian.org. This might be a good subject to discuss with the Debian Developers (Peter Palfrader perhaps). The Tor related ones / debian privacy packaging tools. https://wiki.debian.org/Teams/PkgPrivacyMaintainers Could you ask about this please?

An interesting idea!

It is non-persistent and I remember Debian doesn’t like Tor control command saveconf. (Doesn’t work and they don’t want saveconf to work either.)

We’re kinda inventing something new here. A gui that configures a system daemon.

The Debian way might be: a gui that configures and starts a user service but not using Tor’s systemd unit may be more compliant with Debian policy but actually more troublesome maintenance wise (more doing our own soup than using what everyone uses - bad).

Please define “not connecting”. You mean,

  • DisableNetwork still 1?

    • I was wondering about that. It should be a quite uncommon case so I don’t investigate. If so, please discuss with Marek of Qubes if he would be okay with that reoccurring popup. (The initial Qubes-Whonix implementation was too popup annoying indeed so they might be sensitive about that.)
  • connection failing?

The future of bootstrapping Tor in Whonix needs a wider discussion after Whonix 14 release anyhow. There are some Whonix specific as well as some generic parts. Not easy to cleanly separate.

How’s the boot and connection process in Whonix working currently anyhow? This needs some research and description before we can take further steps. Roughly currently:

whonixcheck vs anon-connection-wizard vs sdwdate-gui vs anon controller (codename) vs https://github.com/troubadoour/tor-control-panel

//cc @troubadour



#576

Yes DisableNetwork still 1.

I totally agreed. We tried to let anon-connection-wizard fix all the Tor booting issue. But I believe anon-connection-wizard should be more like arm, which means anon-connection-wizard will just refuse work when no control socket is found.

And it is other part of the Whonix (probably sdwdate)'s responsibility to let Tor process running and let Tor control socket available.


#577

One disadvantage (or advantage in other terms) of using systemctl is the error message is too general. Usually Tor fails because there is corrupted torrc settings but it never says. It would be helpful if we can at least inform user it is some corrupted torrc setting that make Tor fails to start, like this:

sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config ; echo $?
Mar 15  [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd N/A.
Mar 15  [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 15  [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Mar 15  [notice] Read configuration file "/etc/tor/torrc".
Mar 15  [warn] Failed to parse/validate config: Unknown option 'ds'.  Failing.
Mar 15  [err] Reading config failed--see warnings above.
1

#578

iry:

One disadvantage (or advantage in other terms) of using systemctl is the error message is too general. Usually Tor fails because there is corrupted torrc settings but it never says. It would be helpful if we can at least inform user it is some corrupted torrc setting that make Tor fails to start, like this:

sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config ; echo $?
Mar 15  [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd N/A.
Mar 15  [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 15  [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Mar 15  [notice] Read configuration file "/etc/tor/torrc".
Mar 15  [warn] Failed to parse/validate config: Unknown option 'ds'.  Failing.
Mar 15  [err] Reading config failed--see warnings above.
1

Run sudo -u debian-tor tor --verify-confg?


#579

Hi Patrick!

Sorry for the confusion. Above error is what I intentionally made by writing garbage in /etc/tor/torrc, so no worries. :slight_smile:


sudo tor V.S. sudo -u debian-tor tor

There is a torrc option User which is in the torrc:

user@host:~$ cat /usr/share/tor/tor-service-defaults-torrc | grep User
User debian-tor

When User option is set, we can simply use sudo tor and tor will be run as debian-tor.

When User option is set, when we do sudo -u debian-tor tor, tor will fail to start and complain:

Mar 15 14:56:22.015 [warn] Error setting groups to gid 115: "Operation not permitted".
Mar 15 14:56:22.015 [warn] Tor is already running as debian-tor.  You do not need the "User" option if you are already running as the user you want to be.  (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Mar 15 14:56:22.015 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Mar 15 14:56:22.015 [err] Reading config failed--see warnings above.

Considering User debian-tor option is used by default in Whonix and Debian package, we may use sudo tor here.


#580

iry:

Hi Patrick!

Sorry for the confusion. Above error is what I intentionally made by writing garbage in /etc/tor/torrc, so no worries. :slight_smile:


sudo tor V.S. sudo -u debian-tor tor

There is a torrc option User which is in the torrc:

user@host:~$ cat /usr/share/tor/tor-service-defaults-torrc | grep User
User debian-tor

When User option is set, we can simply use sudo tor and tor will be run as debian-tor.

When User option is set, when we do sudo -u debian-tor tor, tor will fail to start and complain:

Mar 15 14:56:22.015 [warn] Error setting groups to gid 115: "Operation not permitted".
Mar 15 14:56:22.015 [warn] Tor is already running as debian-tor.  You do not need the "User" option if you are already running as the user you want to be.  (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Mar 15 14:56:22.015 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Mar 15 14:56:22.015 [err] Reading config failed--see warnings above.

Considering User debian-tor option is used by default in Whonix and Debian package, we may use sudo tor here.

If we run under user debian-tor most likely we should run tor --verify-config without sudo user change?


#581

Yes. And you also need to remove User debian-tor from torrc if whoami is debian-tor.


#582

Debian original cat /usr/share/tor/tor-service-defaults-torrc includes

User debian-tor

So I wouldn’t want to remove it from /usr/share/tor/tor-service-defaults-torrc.anondist. I would like to abolish /usr/share/tor/tor-service-defaults-torrc.anondist and go back to original /usr/share/tor/tor-service-defaults-torrc as soon as torrc.d is sorted.