Apt-cacher-ng in debian-12-minimal does't work with onion repos

User Support
1

I’m using Qubes OS 4.2 and I have cacher qube based on debian-11-minimal template that use sys-whonix as netvm and debian templates are updating without a problem using this cahcher and onion repos.
Now I’ve created a new cacher qube based on debian-12-minimal template that use sys-whonix as netvm and debian templates can’t update using this cahcher and onion repos but works with clearnet repos.
I’m getting this error in debian template when I try to update it:

Ign:1 http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian bookworm InRelease
Err:1 http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian bookworm InRelease
  503  Host not found [IP: 127.0.0.1 8082]
E: Failed to fetch http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian/dists/bookworm/InRelease  503  Host not found [IP: 127.0.0.1 8082]

I’ve noticed that in debian-12 appvm you can’t use onion repos in sources.list without tor+ anymore while it works in appvms based on debian-11 template (it’s not working for debian-11 as well and now I’m not sure that my memory is correct and if it even worked before):

Err:8 http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian bookworm Release
  Direct connection to .onion domains is blocked by default. If you meant to use Tor remember to use tor+http instead of http.

With Acquire::BlockDotOnion "false"; in apt config it’s starting to work again:

Maybe the default BlockDotOnion value was changed from false to true.
I don’t know if it’s related to this issue or not, maybe apt-cacher-ng now also has BlockDotOnion value set false and it’s causing this issue.
Did anyone succeed in using apt-cacher-ng in qube based on debian-12-minimal with onion repos?

2

I can confirm that the onion repos are working with apt-cacher-ng and without apt-transport-tor in the debian-12-minimal template in Qubes r4.1, so this may be a r4.2 specific problem.

3

Seems to be a problem with apt-cacher-ng version, because after installing apt-cacher-ng 3.7.4 from bullseye-backports in working cacher debian-11-minimal template it’s starting to fail in the same way.

1 Like
4

Thank for sharing your experience. I had the same trouble.

I can confirm that installing apt-cacher-ng with version 3.6.4-1 solved this issue for me. This is the same version debian bullseye uses.

5

Likewise, I’m using apt-cacher-ng version 3.6.4-1 (in Whonix 16, Debian oldstable repo). If reverting to that version works for you, please mark it as the solution for others who may run into the same problem.

6

Reverting the version back is not a proper fix to this problem, it’s just a temporary workaround. I’ll try to build apt-cacher-ng versions between 3.6.4 and 3.7.4 to find the cause of this issue and a possible proper fix to it.

1 Like
7

The problem starts with apt-cacher-ng version 3.7-1 so it’s somewhere in 3.6 → 3.7 code.

8

It seems to be because the apt-cacher-ng starting with version 3.7 is using asynchronous name resolver library (libc-ares) that is dropping DNS requests for “.onion” in compliance with RFC:

9

Discussion about this RFC implementation for c-ares and curl and its impact on transparent Tor proxying:

10

Temporary fix for new apt-cacher-ng versions using privoxy while the issue with RFC is being discussed:

Install and configure apt-cacher-ng in the same way as before, e.g. following this guide:

Install privoxy in template-cacher:

apt-get install privoxy
systemctl mask privoxy

Shut down template-cacher.
Start cacher qube and configure privoxy there:

echo "binds+=( '/etc/privoxy/config' )" >> /rw/config/qubes-bind-dirs.d/50_user.conf
echo 'systemctl unmask privoxy' >> /rw/config/rc.local
echo 'systemctl start privoxy' >> /rw/config/rc.local
echo 'Proxy: http://127.0.0.1:8118' >> /etc/apt-cacher-ng/acng.conf

Restart cacher.
Change privoxy config:

echo 'forward-socks5t / 10.152.152.10:9153 .' >> /etc/privoxy/config
systemctl restart privoxy
3 Likes