Page MenuHomePhabricator

Qubes R4 RC1 - Whonix 13 - updates proxy test failing sometimes
Closed, ResolvedPublic

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

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

Details

Impact
High

Event Timeline

Patrick created this task.Oct 20 2017, 3:07 PM

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.

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.

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.

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

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 closed this task as Resolved.Oct 20 2017, 4:46 PM

Uploaded to jessie-proposed-updates.