Jan 31 2018
Jan 25 2018
Jan 24 2018
TB 7.5 was released today, so you may want to transition this to the stable repository.
Jan 22 2018
(Adjusting tags as reminder.)
Jan 21 2018
Oct 31 2017
Qubes-Whonix DispVMs won't get any more development attention in Qubes
R3.2 because so much has changed. Please look into Qubes R4.
I didn't notice this bug earlier but caught a reference in one of the Qubes mailing list discussions. For what it's worth, I got this to function under Qubes 3.2 by deleting the sdwdate systemd unit files. It has been a while but I think I did that in the whonix-ws template. The dispvm appears to call bootclockrandomization on every start so time correlation is avoided and I no longer encounter times off by 2+ weeks.
Oct 28 2017
Whonix 13: uploaded to jessie-proposed-updates.
Oct 25 2017
Oct 24 2017
Oct 20 2017
Uploaded to jessie-proposed-updates.
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.
tb-updater fix for Whonix 14 / master.
Backported to Whonix 13 tb-updater.
Here is the fix for tb-updater. Please have a look. Untested. Will test now. If it works, I will backport to Whonix 13 tb-updater.
Is that changing to 127.0.0.1 work on Qubes 3.2? Anyway, yes, it should be good enough for Qubes 4.0.
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.
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.
Oct 9 2017
Oct 8 2017
> Just setting `tbb_version` or `tbb_hardcoded_version` variable isn't enough, because it isn't propagated through all the layers to postinst of tb-updater.
Just setting tbb_version or tbb_hardcoded_version variable isn't enough, because it isn't propagated through all the layers to postinst of tb-updater. But creating temporarily a configuration file works (in /etc/torbrowser.d).
Use tbb_version there, because tbb_hardcoded_version is unconditionally overridden by /usr/share/tb-updater/tbb_hardcoded_version. But later is ignored if tbb_version is already set.
marmarek (Marek Marczykowski-Górecki):
marmarek added a comment.The problem is back again, 7.0.4 is no longer available at https://dist.torproject.org/torbrowser/ What is the easiest/elegant way to choose different version, without modifying tb-updater package? Some env variable? Some config file? I don't consider https://github.com/SimonSelg/qubes-template-whonix/blob/SimonSelg-fix-tb-updater/whonix-gateway/04_install_qubes_post.sh#L65-L79 elegant...
Oct 7 2017
The problem is back again, 7.0.4 is no longer available at https://dist.torproject.org/torbrowser/
What is the easiest/elegant way to choose different version, without modifying tb-updater package? Some env variable? Some config file? I don't consider https://github.com/SimonSelg/qubes-template-whonix/blob/SimonSelg-fix-tb-updater/whonix-gateway/04_install_qubes_post.sh#L65-L79 elegant...
Aug 30 2017
Aug 28 2017
Fixed package uploaded to jessie-proposed-updates.
Aug 26 2017
Yes, it works now: https://travis-ci.org/marmarek/qubes-template-whonix/builds/263033873
Aug 25 2017
The idea was to keep X newest entries. not oldest, right? So the first order is right (the code skip X "first" directories). Also, I'd trust more file names, not modification time - the later is easy to mess up (and a consequence will be removing wrong directory - possibly containing just modified data).
Aug 24 2017
tb-updater with updated hardcoded Tor Browser version is now available in Whonix jessie-proposed-updates repository. Could you try a build please? Quite likely it will go past that issue now.
The version with that fix is now available from jessie-proposed-updates.
That works better. But still not sufficient. It's in the wrong order.
Aug 15 2017
I've tried glob, but I need reversed order and failed to do that with glob. ls -dr should do. Unless $tb_browser_folder itself contains spaces...
Thank you very much for the PR!
Aug 12 2017
Proposed fix here: https://github.com/Whonix/tb-updater/pull/1
Aug 10 2017
Indeed, TEMPLATE_OPTIONS variable wasn't properly propagated. Fixing this fixes whonix-gateway build:
Aug 9 2017
tb-updater must not be installed on Whonix-Gateway at all cost. It's a blocker, since that messes up a carefully selected and package selection.
Also, it worked before (when tor browser 7.0 was still downloadable)... See builds history on travis (https://travis-ci.org/marmarek/qubes-template-whonix/builds).
In above linked travis job, workstation build (17.6) fails with:
(Debugging information: curl_status_message:  - [HTTP page not retrieved. The requested url was not found or returned another error with the HTTP error code being 400 or above. This return code only appears if -f, --fail is used.])
Probably package installation order is non-deterministic here...
In whonix-ws the package is called anon-ws-dns-conf . Yes I'm sure about that. The build log explicitly says "Couldn't resolve host".
Are you sure about that? According to build log, the issue with whonix-ws is missing 7.0.0 version on server. anon-gw-dns-conf is not installed in whonix-ws