Debian 12 (bookworm) Template has broken DNS resolution when using http_proxy=http://127.0.0.1:8082/ (Qubes UpdatesProxy) (tinyproxy)

[adrelanos]

Qubes OS release

4.1

Brief summary

Setting http_proxy=http://127.0.0.1:8082/ is broken in debian-12 (bookworm) Template.

Steps to reproduce

Use debian-12 (bookworm) Template.

http_proxy=http://127.0.0.1:8082/ curl https://check.torproject.org

Expected behavior

Functional DNS.

Actual behavior

Broken DNS.

curl: (6) Could not resolve host: check.torproject.org

Additional information

This is reproducible if sys-net (UpdateVM) is using as Template:

• debian-11
• debian-12
• fedora-38

Template:

• This did not happen with debian-11 (bullseye) Template.
• Only debian-12 (bookworm) Template is affected by this bug.

dom0 journalctl qubes qrexec-policy-daemon does not see the request when using DNS. (It does see the request when using IP.)

It could be that curl (and other applications) are using http_proxy=http://127.0.0.1:8082/ for IP but ignore it for DNS resolution.

Impact

Breaks various things, including:

• curl repository signing key download
• extrepo: http_proxy=http://127.0.0.1:8082/ sudo extrepo enable kicksecure
• flatpak: http_proxy=http://127.0.0.1:8082 flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
• Qubes-Whonix: Tor Browser updates by update-torbrowser running inside Template

[marmarek]

Have you tried setting https_proxy too?

[adrelanos]

Setting https_proxy fixes the issue.

Any idea why this is happening? Seems like curl, extrepo, flatpak all use some application / library that now requires https_proxy for https links?

Are any updates in Qubes source code or documentation required?

Should A)

• http_proxy=http://127.0.0.1:8082/ be changed to
• https_proxy=http://127.0.0.1:8082/

or B)

• http_proxy=http://127.0.0.1:8082/ https_proxy="$http_proxy"
• Seems useful for documentation for compatibly with Debian bullseye and bookworm during the migration period.

or C)

• ALL_PROXY=http://127.0.0.1:8082/
• Don't know how widely supported this is.
  • Works with curl.
  • Works with flatpak
  • Fails with extrepo.

?

Btw, there's also NO_PROXY mentioned in the curl man page.

NO_PROXY <comma-separated list of hosts/domains>

[marmarek]

TBH, I'm not sure why just http_proxy worked for you before, as long as I remember using proxy for HTTPS with curl and others always required setting https_proxy. Maybe previous version had it set somewhere else? Or HTTP (onion?) links were used?

Anyway, option B looks better, especially if onion URLs are used anywhere.

[adrelanos]

Thank you!

This is now functional for Whonix.

Should there be something to do here for Qubes, please re-open.