Tor browser downloader fails in whonix-workstation-17 template

When running update-torbrowser in whonix-workstation-17 template, I get this error:

INFO: ARCH 'x86_64' detected.
INFO: ARCH_DOWNLOAD 'linux-x86_64' detected.
INFO: CURL_PROXY: '--proxy http://127.0.0.1:8082/'
INFO: Automatically setting download folder to '/var/cache/tb-binary', because running inside Qubes Template but not run from postinst. This is useful so you get up to date versions of 'Tor Browser' in newly created App Qubes inherited from updated Templates.
More info: http://www.whonix.org/wiki/Tor_Browser/Advanced_Users#Qubes-specific
INFO: Not running inside Qubes Disposable Template, ok.
INFO: Using stable version. For alpha version, see: http://www.whonix.org/wiki/Tor_Browser#Alpha
INFO: Running network interface available check... ERROR: No network access.

Please check: Start menu -> System -> systemcheck
         or in Terminal: systemcheck
         or in Terminal with debugging: systemcheck -v

Run systemcheck on Whonix-Gateway as well.

If systemcheck reports no problems with internet activity and downloading Tor Browser still fails, please report a bug!

Debugging information:
/usr/libexec/helper-scripts/check-network-access non-zero exit code.
zsh: exit 18    update-torbrowser

Running update-torbrowser in a disposable works just fine, although the update is of course not persistent.

The issue seems to be that update-torbrowser (or check-network-access) assumes that there is no internet access because there are no intervaces besides lo. Of course, the lack of interfaces is expected. It should instead use the proxy at http://127.0.0.1:8082. Testing the proxy using curl --proxy http://127.0.0.1:8082/ http://www.whonix.org reveals no problems.

Edit: Running update-torbrowser in an appvm works and causes the update to be persistent, but not for disposables created from that appvm.

This issue occurred after enabling the whonix apt repository according to the advice on this issue: https://forums.whonix.org/t/tor-browser-update-problem-91-no-ocsp-response-received/21739/6. I did this by re-installing the whonix-workstation-17 template because apparently it is enabled in the most recent version of the template but not the one instaled by default in qubes https://forums.whonix.org/t/derivative-repository-kicksecure-whonix-unexpectedly-not-enabled-by-default-in-qubes-whonix/21834/3

3 Likes

This can probably be solved by just making the network checker unconditionally say “yes, there is a network connection” in Qubes templates, since there really isn’t any way of knowing if there is or isn’t (other than querying sys-net’s Internet connectivity, which would be cool but isn’t doable yet to my awareness).

2 Likes

An update that fixes this issue has been uploaded just now.

2 Likes

Thank you very much!

2 Likes