Deploy curl-proxy/wget-proxy scripts so users can add GPG distro keys linked to added external repositories #7386
Description
EDIT: PoC here
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