Will be there traffic leaks if to use wget and apt-transport-https in a Whonix template?

Larker · August 17, 2025, 9:25pm

I wanted to install Element client in Whonix template but it’s not present in regular repository. On official site they give this command to install wget and apt-transport-https in order to add Element repos and only then it’s possible to install Element itself:

sudo apt install -y wget apt-transport-https
‍
sudo wget -O /usr/share/keyrings/element-io-archive-keyring.gpg https://packages.element.io/debian/element-io-archive-keyring.gpg
‍
echo "deb [signed-by=/usr/share/keyrings/element-io-archive-keyring.gpg] https://packages.element.io/debian/ default main" | sudo tee /etc/apt/sources.list.d/element-io.list

sudo apt update

sudo apt install element-desktop

But I’m not sure if there will be no clearnet traffic leaks if to use wget and apt-transport-https in template. I installed first only wget and tried to add repos without apt-transport and saw nothing in Onion Circuits. No connections using circuits. Though sys-whonix is set as update proxy for templates and dom0 (and as netvm for all qubes that have network enabled). Yes, I’ve got error saying it can’t resolve those addresses, probably because it can’t download those repos through http, but still, I didn’t see any connections in Onion Circuits when I tested wget. I expected they should have appear when wget was trying to connect to those addresses. Am I worrying for nothing or there really can be traffic leaks because of wget and apt-transport-https?

Patrick · August 19, 2025, 5:11am

No leaks:

Deploy curl-proxy/wget-proxy scripts so users can add GPG distro keys linked to added external repositories

opened 06:24PM - 28 Mar 22 UTC

closed 04:00AM - 16 Aug 22 UTC

tlaurion

C: templates ux R: declined P: default

EDIT: PoC [here](https://forum.qubes-os.org/t/curl-proxy-wget-proxy-scripts-in-t…emplates-so-users-can-add-gpg-distro-keys-linked-to-added-external-repositories/10935/37?u=insurgo) This implements wget and curl wrappers, blocking when usage happens in TemplateVM without internet access (considering that TemplateVM is considered secure). The code presented there could be modified as the next use case (TemplateVM with netvm assigned) to only pause for 3 seconds warning the user of the original wget/curl command going to happen next and telling the user to CTRL-C now if that command was not intended. That sleeping of 3 seconds was implemented so that unattended scripts would still work out of the box, without the user having to copy one line at a time, if the wrapper scripts were to ask the user for input prior of continuing, which would have broke caller scripts (and stopping bash scripts and other to automatize software installation scripts). I encourage people reading this to comment directly in the forum post for discussion, or here for implementation suggestion to make it more acceptable. Those threads were immense. This is the get home message/PoC for users exploration. ### The problem you're addressing (if any) Customers/users are struggling everyday with installing software in templates that are not part of standard repositories. This won't fix the bigger problems of personas or having different classes of softwares being installed by default without manual intervention, but at least, this permits users to download gpg signing keys as a near drop in replacement to installation instructions given by upstream guides, permitting users to follow generally the installation instructions that exist, without playing around too much to apply those instructions. Otherwise, users punch holes in their configuration, assigning a network vm to their templates, more or less diligently denying internet access but punching exception for it to work for the next 5 minutes only, which opens a big door to downloading other crap for users trying to launch gui-installers and possibly do important damage in their templates. Or requiring from those users to download gpg keys in disposable qubes and having to move the gpg public key back into the template, which implies of them of being able to decode/understand installation instructions (most of them can't and that complexifies onboarding). The solution is not to deploy snap. Users need to be able to economize disk space without having applications deployed directly from snap repositories and duplicating the network bandwidth required for all their qubes where snap packages are deployed. Users also need to know that they need to update their software, prior of launching them. Snap is confusing with no warning given that a new version is downloaded and installed but not currently running. The solution is not to have software providers create specific Qubes installation instructions either. ### The solution you'd like The real solution is to have a mostly direct translation of commands that won't work out of the box, so that those additional repositories can be added in the proper templates without complication. solution is to have those templates warn the user when they need to be updated, with the same expected warnings of templates to be updated, and same GUI UX warning them that they should restart their qubes consequently. The solution presented here is creating a new curl-proxy command to be used by users into replacing wget/curl calls. Simple fix to a really big UX problem. See the following signal-desktop/session-desktop examples (not perfect here, as you will see withsignal-desktop, the wrapper should parse what is given and maybe clean it prior of redirecting input. `-O-` was manually removed: the user would just don't know.) Thanks again for your work in UX!!!! in debian-11 template: `sudo apt install curl` # curl-proxy ``` #!/bin/env bash curl --proxy http://127.0.0.1:8082/ --tlsv1.2 --proto =https --max-time 180 "$@" ``` # wget-proxy ``` #!/bin/env bash https_proxy=http://127.0.0.1:8082/ http_proxy=http://127.0.0.1:8082/ wget --secure-protocol=TLSv1_2 --timeout=180 "$@" ``` ### Examples #### Session-desktop documentation (https://deb.oxen.io/) drop in replacement: ``` sudo curl -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg echo "deb https://deb.oxen.io $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/oxen.list sudo apt update sudo apt install session-desktop ``` Here the user would have to replace: `sudo curl -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg` to `sudo curl-proxy -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg` #### Signal-desktop instructions (https://signal.org/download/linux/) drop-in replacement: Upstream instructions: ``` wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg cat signal-desktop-keyring.gpg | sudo tee -a /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' |\ sudo tee -a /etc/apt/sources.list.d/signal-xenial.list sudo apt update && sudo apt install signal-desktop ``` Here the following line needs to be changed: `wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg` becomes `wget-proxy -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg` ### The value to a user, and who that user might be Be able to follow a single Qubes documentation explaining the conversion from instructions read online requiring to download gpg keys, why it won't work and what to replace by what. Be able to be autonomous into installing software. Edit: added wget-proxy based on additional experimentations and discussions that happened under https://forum.qubes-os.org/t/installing-software-in-qubes-all-methods/9991/10