Qubes R4 RC1 - Whonix 13 - updates proxy test failing sometimes

[phabricator-migrator]

Information

ID: 723
PHID: PHID-TASK-njw3fbmteq43ozgtqlh4
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: High

Description

The following is showing a false positive.

https://github.com/Whonix/qubes-whonix/blob/Whonix13/usr/lib/qubes-whonix/qubes-whonixsetup#L41

    # Display warning that TemplateVM is not connected to a Tor update proxy.
    if [ ! -e '/var/run/qubes-service/whonix-secure-proxy' ]; then
        /usr/lib/qubes-whonix/alert update /usr/lib/qubes-whonix/messages.yaml
    fi

Something in

• https://github.com/Whonix/qubes-whonix/blob/Whonix13/usr/lib/qubes-whonix/init/torified-updates-proxy-check
• or https://github.com/Whonix/qubes-whonix/blob/Whonix13/usr/lib/qubes-whonix/utility_functions.sh

Must be wrong.

The timeout is currently set to 10. Perhaps it’s enough to increase it?

What do you think would be a safe value even covering slow machines? @marmarek

Comments

---

Patrick

2017-10-20 13:11:10 UTC

A timeout might not be sufficient? Just starting the whonix-gw (or whonix-ws) template alone does not result in invoking Qubes updates proxy qrexec call and thereby starting sys-whonix? Imagine the user just starting whonix-gw (or whonix-ws) and then getting distracted, doing something else, not upgrading.

---

marmarek

2017-10-20 13:18:55 UTC

sys-whonix is started by first request to updates proxy (if not already running). In most cases it will be that connectivity check. I think connect timeout doesn’t matter here, as connection (in terms of TCP) is to localhost, instant. Only the response comes later.
I guess the problem is that the warning is displayed, while the connectivity check is still running (i.e. race condition). Since sys-whonix takes some time to start, it happens reliably. Maybe some dependencies between those services would help (is it possible to order GUI application after system service startup?). Or some lock file to synchronize those things?
If none of above is possible, some solution would be ordering connectivity check with Before=qubes-gui-agent.service. But I’d treat this as last resort.

---

Patrick

2017-10-20 14:38:37 UTC

While I was at it, improved that popup message a bit. It’s hard for me to word what to say in such a situation.

update "Whonix-Gateway NetVM required for updates" popup message · Whonix/qubes-whonix@d4d47b9 · GitHub

This check makes less and less sense since Qubes R4. I never liked having that check in the Qubes-Whonix package. It doesn’t have the right infrastructure there to support it. If anything, it belongs to #whonixcheck. There is T656 for that.

Fixing that race condition is very hard. See T424 for research and attempts to fix that.

Meanwhile I backported the Whonix 13 solution which waits up to 120 seconds.

https://github.com/Whonix/qubes-whonix/commit/c6ab06fcc27d4d76e9c90eeef6ee8e2c9c7644a3

Good enough?

---

Patrick

2017-10-20 14:46:05 UTC

Uploaded to jessie-proposed-updates.