About qrexec



I was curious to trying out the various methods mentioned above so I made a deb-signal template only to find out none seem to work:

wget :

$ export https_proxy=
$ wget -O- https://updates.signal.org/desktop/apt/keys.asc
Connecting to… connected.
Proxy tunneling failed: CONNECT denied (ask the admin to allow HTTPS tunnels)Unable to establish SSL connection.

curl :

$ curl --proxy --tlsv1.2 --proto =https --max-time 180 “https://updates.signal.org/desktop/apt/keys.asc
curl: (56) Received HTTP code 403 from proxy after CONNECT

I then noticed that when launching the command, my apt-cacher qube was started and I found the following command to be working:

curl --proxy --tlsv1.2 --max-time 180 “http://HTTPS///updates.signal.org/desktop/apt/keys.asc

So I had to remove --proto =https and change https:// to http://HTTPS/// .

Is this behavior to be expected when not dealing with repositories but an apt-cacher qube is enabled?

@BEBF738VD I think you are mixing again networking with qrexec.

Simple Sven’s command

curl --proxy -s https://updates.signal.org/desktop/apt/keys.asc | apt-key add -"

is enough to import key to any non-networked qube, all over qrexec.

Not any non-networked qube. The use of the UpdateProxy is configured in an respective policy which by default only allows templates to use it.

Ah thank you, appreciate the thread.
Unfortunately that command does not work for me:

$ curl --proxy https://updates.signal.org/desktop/apt/keys.asc
curl: (56) Received HTTP code 403 from proxy after CONNECT

Like I said, I did try various options and in order for it to work I need to change the url of the resource to fetch from https:// to http://HTTPS///

Of course.

That is why I left the link behind “non-networked qube”, to show to the ones interested in how any non-networked qube can be set up to be updated via qrexec too, by customizing policies beside other steps needed to be taken to.

You are welcome. I’ve seen this already, but it worked for me. It’s obvious that you are connected to the proxy and that the problem is that the access after it is forbidden, so most probably it’s not about qrexec but with the network. Did you check this topic?

I have but I’m only able to fetch resources through the proxy if I change their url to http://HTTPS///. Any other solution does not work. Not a big deal though.

OK, I thought other users would want to see the resolution, for example what would happen if your cacher qube is attached to sys-whonix, what the outcome would be if it’d be attached to sys-firewall instead…
Sorry I can’t be of a bigger help.

I tried both and the outcome is the same.

No worries at all, any help is always welcome. Luckily in my case a workaround makes things work anyway.

1 Like