qubes-whonix build failure

[phabricator-migrator]

Information

ID: 710
PHID: PHID-TASK-espagekcugavsefirmzk
Author: marmarek
Status at Migration Time: resolved
Priority at Migration Time: High

Description

Build of Whonix templates for upcoming Qubes 4.0 fails on downloading torbrowser. And interestingly, this applies also to Qubes 3.2 templates, which previously worked fine. So, probably it isn’t related to 3.2/4.0 difference at all.

Full build logs:

https://travis-ci.org/marmarek/qubes-template-whonix/builds/258845862

Specific message:

https://dist.torproject.org/torbrowser could not be reached.

Possible reasons:
- https://dist.torproject.org/torbrowser is down
- download location changed

Please check: Start menu -> System -> Whonix Check
              or in Terminal: whonixcheck
              or in Terminal with debugging: whonixcheck -v

If whonixcheck reports no problems with internet activity and downloading Tor Browser keeps failing, please report a bug!

(Debugging information: curl_status_message: [6] - [Couldn't resolve host. The given remote host was not resolved.])

Comments

---

Patrick

2017-07-29 15:40:39 UTC

The build was done using jessie-proposed-updates, which is still at tbb_hardcoded_version="7.0.0", that download version was removed from torproject’s download server. tbb_hardcoded_version wasn’t updated to prevent more breakage due unresolved T671.

---

marmarek

2017-07-29 22:20:09 UTC

What does it mean in practice?
Also “Couldn’t resolve host” doesn’t look like file removed from torproject’s download server…

---

Patrick

2017-07-31 10:50:07 UTC

! In T710#14256, @marmarek wrote:
What does it mean in practice?

Not having a deb package for Tor Browser while at the same time wanting preinstallation of Tor Browser and deterministic builds continues to create a mess. Builds will break as Torproject keeps deleting old versions and/or changing file locations.

Solution:

• workaround: Template build should set export tbb_hardcoded_version="7.0.3" and hope it makes all the way down to /usr/bin/update-torbrowser.
• Whonix 13 stable tb-updater package upgrade
  ** update to 7.0.3 - tb-updater/usr/share/tb-updater/tbb_hardcoded_version at Whonix13 · Kicksecure/tb-updater · GitHub
  ** but somehow also find a solution for T671
  *** Whonix 13 short solution: turn off for Whonix 13
  *** Whonix 14: real fix for T671

Also “Couldn’t resolve host” doesn’t look like file removed from torproject’s download server…

Probably transient issue… Because…

From https://s3.amazonaws.com/archive.travis-ci.org/jobs/258845866/log.txt?X-Amz-Expires=29&X-Amz-Date=20170731T103501Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170731/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=701eed06909cdcc0ebb19521abd90cce2491a0c55a1b03c518a498a778d2b8c0

This worked:

+++ /usr/lib/curl-scripts/curl-prgrs --fail --fail --tlsv1.2 --proto =https --max-time 180 --output /var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder https://dist.torproject.org/torbrowser

This failed:

+++ /usr/lib/curl-scripts/curl-prgrs --fail --fail --tlsv1.2 --proto =https --max-time 180 --output /var/cache/tb-binary/.cache/tb/files/sha256sums.txt.asc https://dist.torproject.org/torbrowser/7.0/sha256sums.txt.asc
+++ curl_exit_code=22

(Because of T710#14252.)

---

SimonSelg

2020-12-09 16:05:01 UTC

---

Patrick

2017-08-06 20:54:08 UTC

True.

tb-updater should not be installed on Whonix-Gateway anyhow. That’s
strange. That’s the root cause to be fixed.

Thanks for looking into it! Development help very much needed at this
point. Please keep digging.

---

SimonSelg

2017-08-08 23:46:24 UTC

I tested the build whonix-gw and whonix-ws templates I build using my patch to [[https://github.com/SimonSelg/qubes-template-whonix/blob/SimonSelg-fix-tb-updater/whonix-gateway/04_install_qubes_post.sh#L65-L79 | qubes-template-whonix ]] and my [[ In templates.conf only override RELEASE when it is not set. by SimonSelg · Pull Request #24 · QubesOS/qubes-builder · GitHub | patch to qubes-builder ]] and everything works just fine (on 4.0 RC1).

Which means whonix-gw and whonix-ws could be included in Qubes 4.0.

My patch doesn’t solve the core issue (tb-updater gets installed while anon-gw-dns-conf is already in effect), it does the following two things:

• Work around connectivity issue by installing tb-updater before installing the pack of packages containing anon-gw-dns-conf
• It patches tbb_hardcoded_version in tb-updater to 7.0.3 since the package hasn’t been pushed to the repo (T690)

I could create a PR to qubes-template-whonix if there is any interest.

---

marmarek

2017-08-08 23:42:51 UTC

I prefer the proper fix, which is a chain of three tickets in total: ⚓ T671 old Tor Browser versions in /var/cache/tb-binary/.tb/ accumulate in Qubes-Whonix, users run into full up disk error issues
Independently (not a blocker), it would be good to find out why tb-updater is installed in whonix-gw.

---

SimonSelg

2020-12-09 16:05:38 UTC

---

marmarek

2017-08-08 23:56:25 UTC

Ah, you’re right. So the second line in my comment is a blocker too.

---

SimonSelg

2020-12-09 16:05:26 UTC

---

marmarek

2017-08-09 00:07:54 UTC

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

---

SimonSelg

2017-08-09 00:12:39 UTC

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”.

Also, if you watch the build log you can see that in both whonix-gw and whonix-ws tb-updater and anon-{ws|gw}-dns-conf gets installed at the same time.

I verified that by stopping the build process, chrooting into the image and tested it there myself.

I’ll start a new build and verify it again tho.

---

marmarek

2017-08-09 00:23:45 UTC

In above linked travis job, workstation build (17.6) fails with:

(Debugging information: curl_status_message: [22] - [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…

---

marmarek

2017-08-09 00:28:31 UTC

Also, it worked before (when tor browser 7.0 was still downloadable)… See builds history on travis (Travis CI - Test and Deploy with Confidence).

---

SimonSelg

2020-12-09 16:04:32 UTC

---

Patrick

2017-08-09 07:54:19 UTC

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.

From https://s3.amazonaws.com/archive.travis-ci.org/jobs/258845867/log.txt?X-Amz-Expires=29&X-Amz-Date=20170809T074523Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170809/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=36184d2b752e87e36457a6ba48b1ca279482e37e1c2558cdd6345601ceda11bf … This is might be the cause:

+ /usr/sbin/chroot mnt eatmydata apt-get -o Dpkg::Options::=--force-confnew --yes -o Acquire::Retries=3 -o Dpkg::Options::=--force-unsafe-io install qubes-whonix-gateway

Whonix used to be build using builder.conf:

TEMPLATE_ALIAS += whonix-gateway:jessie+whonix-gateway+minimal+no-recommends

This results in Qubes builder using apt-get with --no-install-recommends. Looks like this is what’s missing in this build?

---

marmarek

2017-08-10 11:16:51 UTC

Indeed, TEMPLATE_OPTIONS variable wasn’t properly propagated. Fixing this fixes whonix-gateway build:
Travis CI - Test and Deploy with Confidence

---

Patrick

2017-08-24 15:17:43 UTC

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.

---

marmarek

2017-08-25 23:38:36 UTC

Yes, it works now: Travis CI - Test and Deploy with Confidence

---

marmarek

2017-10-07 13:39:44 UTC

The problem is back again, 7.0.4 is no longer available at Index of /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…

---

Patrick

2017-10-07 23:12:50 UTC

marmarek (Marek Marczykowski-Górecki):

marmarek added a comment.

The problem is back again, 7.0.4 is no longer available at Index of /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…

Agreed.

tb-updater (update-torbrowser script) as is should already support
environment variables for example tbb_hardcoded_version="7.0.6".

So

export tbb_hardcoded_version="7.0.6"

should do. Long time untested. Might have worked when Qubes-Whonix was
new if I remember right. Could you try that please?

The question is if that environment variable flows down from
qubes-template-whonix through sudo (?), through apt-get, through
tb-updater’s debian/postinst to the actual update-torbrowser script?

---

marmarek

2017-10-08 08:56:32 UTC

https://github.com/Whonix/qubes-template-whonix/pull/1

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.

---

Patrick

2017-10-08 09:52:22 UTC

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.

That’s unfortunate. I wonder why that is.

(Yes, tbb_version already set works and then tbb_hardcoded_version
is ignored.)