I noticed that when using Tor Browser with media or high security level, the select code function does not work. There is no such a button anymore. What I did was double left-click my mouse to select all and the tricky thing is it actually select something like:
\n
code
\n
Therefore, when I copy and paste the selected thing to the Konsole, it will actually not work the first time I do a choice on [y/n].
This is definitely not a Whonix issue, but other testers may be aware of it now.
These two commands seems inflexibly related to the name of two VMs:
sudo qubesctl state.sls qvm.anon-whonix
sudo qubesctl state.sls qvm.updates-via-whonix
Should people who use Whonix in Qubes always have anon-whonix and sys-whonix?
It turns out every time I (re)boot up the gateway, it will complain about ERROR: whonix_firewall failed to load!. And I have to do a sudo whonix_firewall to temporarily fix it.
I even tried to reload the firewall in template whonix-gw (not sure if I should do that), but the problem still exists.
I also had this experience on Qubes upgrade - both in 3.2 and 4.
As stated, systemctl status whonix-firewall shows it is masked.
Removing the mask and enabling the service in the template allows sys-whonix to start as expected.
(Question - is this the right thing to do? Or is there service that will run in sys-whonix that will unmask and enable?)
N.B Because the service is initially masked, whonixcheck takes a loooong time to produce any output.
Once this is fixed, sys-whonix started with firewall enabled and running.
I found that in 4.0rc5 whonixcheck in sys-whonix reports that Tor is disabled, although systemctl status shows it is running.
Trying to enable using whonixsetup results in error 0 unable to add "DisableNetwork 0" to /usr/local/etc/torrc.d/40_anon_connection_wizard.conf.
Indeed that file does not exist, although 95_whonix.conf does in same location.
ust because the torrc parsing result is DisableNework 0 does not necessarily mean Tor is connected to the Tor network. For example:
Tor process may even not start (because of a corrupted torrc option)
Tor process starts, but DisableNetwork is set to 1 through control port/socket without writing to any torrc files.
This commit is an experimental demonstration on if we should talk to Tor control port directly. There are three questions need answering before adopting it:
Q: Can we say Tor is not enabled just because cookie does not exit?
Q: Can we say Tor is not enabled just because its control port does not exit?
Q: Shall we make it another check to say if Tor control socket is available?
I don’t think this is good. Why should we parse fewer files there? If
the code is broken, it should be fixed so it would still generically
parse all files.
I also had this experience on Qubes upgrade - both in 3.2 and 4.
As stated, systemctl status whonix-firewall shows it is masked.
Removing the mask and enabling the service in the template allows sys-whonix to start as expected.
It whonix-firewall.service shouldn’t be masked to begin with. That might
be the root cause. I wonder what I masking it.
There was a migration from package whonix-gw-firewall /
whonix-ws-firewall to whonix-firewall package:
If /usr/local/etc/torrc.d/40_anon_connection_wizard.conf exists but does
not include #DisableNetwork 0, then ed -s /usr/local/etc/torrc.d/40_anon_connection_wizard.conf [...] will fail.
Please fix.
Indeed that file does not exist, although 95_whonix.conf does in same location.
So it must be yet another bug. Running with bash -x might help to find
out why it’s not created by whonixsetup?
Because I was thinking since Whonix 14 is not really using %include directory feature by default, parsing all the files will also parse those are not actually used by Tor. This may cause whonixcheck has different result from what Tor is really using (like what happened to unman, whonixcheck complains about Tor is disabled while Tor works fine. )
For example, if there is a file called 60_xx.conf or 50_user.conf~ which contains an option DisableNetwork 1. The files are never used by Tor but they will be parsed by whonixcheck and then whonixcheck think Tor is disabled.
I agree that we should generically parse all the files but maybe only after Whonix really supports %include directory by default?
At that time, I can do a PR to parse all the files ends with .conf .
When parsing the torrc file, we switch from command line flavor to using the python functions availabed in anon_connection_wizard package.
The advantages are as follows:
Better consistency with anon_connection_wizard style parsing
While the command line flavor parsing comments (out) #DisableNetwork 0, anon_connection_wizard writes DisableNetwork 0 or DisableNetwork 1 to 40_connection_wizard.conf . This can be a issue when user uses both anon-connection-wizard and whonixsetup for at least once. Using the same implementation will aviod the inconsistency.
More robust in handling different cases
Considering the inconsistency descriped above, the command line flavor parsing was not robust enough. For example, it will assume the final value in anon_connection_wizard.conf is 0 right after it sees a DisableNetwork 0 line. This will ignore the case where there is also a DisableNetwork 1 line after it.
Lower maintanance cost
It allows us to only maintance one piece of code.
Simplified the logic in the bash script
The disadvantages are as follows:
anon-connection-wizard becomes a dependency of whonixsetup now
However, since whonixsetup should be installed in both Whonox-Gateway and Whonox-Workstation, but anon-connection-wizard should NOT be installed in Whonix-Worksatation, we cannot claim the dependency in Debian control.
Less error info in CLI
The error happens in the python function may not be well-reflected to the CLI which is seen by user. For example, user may only know the attempt to enable Tor failed, but does not know if the problem is because of the missing of anon_connection_wizard package or anything else.
It didn’t happen to unman as far as I understand. It’s not what he reported.
The report is a mismatch between Tor enabled and Tor systemd running status. They are related. Sound the same rationally but are different on technical level. That is causing confusion.
we could even call it a bug calling the folder .d if not all of it gets parsed but we also don’t want to change implementation too much back and forth to finally get the release out
simply ignoring config files not parsed here that would disable Tor if above bug didn’t exist also seems bad
First whonix-firewall (new merged package) gets installed. Then either whonix-gw-firewall or whonix-ws-firewall package (old separate package) gets autoremoved. The latter may be running the prerm / postrm Debian maintainer scripts which disables systemd. Could be a bug in the Debian package migration process.
Generally it’s good to have code to check these things.
Could you please grep all of Whonix code to see how check_tor_enabled_do is used? It’s used multiple times. Changing it could break various things. Would require a rebuild of Whonix and test.
check_tor_enabled_do is a bad function name chosen by me back then. It’s more like check_tor_networking_enabling_in_config_do and specific as that.
Q: Can we say Tor is not enabled just because its control port does not exit?
file_name_list+=" "
if [ ! -e “/var/run/tor/control” ]; then
TOR_ENABLED="1"
return 0
fi
fi
Not in that function check_tor_enabled_do. Config might be DisableNetwork 0 but but some other error prevents Tor from starting. Then whonixcheck would advice to run Whonix Setup to enable Tor but this is not really the issue.
This needs to be protected by timeout. Please refer to other uses of timeout in Whonix source code. Also needs exit code checking since likely to exit non-zero in error case.
Maybe a new separate whonixcheck test in the appropriate order? There are quiet a few check_tor_… tests already.
Besides the known bugs on the Whonix and Qubes issue trackers, this should be ready as stable Whonix 14 release. Only waiting for new Qubes templates to be built and tested before the Whonix 14 release will be made.
