Build from source fails when using tor

[tetrahedras]

When building from source on a fedora-30 VM which is using sys-whonix as a NetVM, the Docker build script continually fails at sexplib0.v0.12.0 with the error "Curl failed." It looks like something is blocking connections from Tor.

[palainp]

Hi, thanks for reporting this issue, I just configured sys-whonix and anon-whonix to try and reproduce. A lot of things have changed since your issue in mirage, but I can confirm that I also had the same failure with the current mirage (4.3.1) once.
But surprisingly, after the curl failed it worked with a second make depend.
Would you mind to try to run make depend a second time if it fails?

And now after cleaning the repository and/or using a fresh qmf clone it works fine every time... I guess that we can have trouble with timeouts when using tor, or I had a circuit change during the make depend process, don't know why it also appears on the same package sexplib.

[tetrahedras]

On Wed, Nov 16, 2022 at 12:40:31AM -0800, Pierre Alain wrote: Hi, thanks for reporting this issue, I just configured sys-whonix and anon-whonix to try and reproduce. A lot of things have changed since your issue in mirage, but I can confirm that I also had the same failure with the current mirage (4.3.1) once. But surprisingly, after the `curl failed` it worked with a second `make depend`. Would you mind to try to run `make depend` a second time if it fails? And now after cleaning the repository and/or using a fresh qmf clone it works fine every time... I guess that we can have trouble with timeouts when using tor, or I had a circuit change during the `make depend` process, don't know why it also appears on the same package sexplib.

I was trying to reproduce this but my laptop (and the DispVM I was compiling in) died due to QubesOS/qubes-issues#7910 Short answer: yes, it may work intermittently if the Tor circuit changes. If someone is blocking Tor exit nodes, their list of exit nodes may be out of date. When you change circuits (and exit nodes) you may end up at an exit node that isn't blocked.

[palainp]

Thanks for your reply, I'm still a bit buzzled as to why it fails on the exact same package, and, for me, github doesn't filter Tor at all (as the curl command points to a sexplib binary release on github).

Now the issue sounds unrelated to qubes-mirage-firewall. If you manage to build with success when the sleep issue is fixed, I think we can close this issue.

[palainp]

I think the exact same package failure is just a coincidence, I now had the following failure:

...
 ↳ fetch monorepo rependencies in the duniverse folder
==> Using lockfile mirage/qubes-firewall-xen.opam.locked
opam-monorepo: [ERROR] Failed to pull /home/user/qubes-mirage-firewall/duniverse/io-page: https://github.com/mirage/io-page/releases/download/v3.0.0/io-page-3.0.0.tbz (Curl failed: "/usr/bin/curl --write-out %{http_code}\\n --retry 3 --retry-delay 2 --user-agent opam/2.1.3 -L -o /home/user/qubes-mirage-firewall/duniverse/io-page/io-page-3.0.0.tbz.part -- https://github.com/mirage/io-page/releases/download/v3.0.0/io-page-3.0.0.tbz" exited with code 6)
make[1]: *** [Makefile:43: pull] Error 1
make: *** [Makefile:53: depend] Error 2

and another make depend succeed immediately.