Why does the UpdateProxy not have a whitelist?

As always your guidance is highly appreciated. I think the correct way to approach this is to ask for background first as @Insurgo did:

I’ll branch this off as a new thread and hope we can as a community retrace and understand what happened before by using archives etc. without bothering the actual developers too much. Then when a clearer picture emerges, @Insurgo or myself might decide to take it to qubes-devel.

Thank you!

1 Like

@adrelanos @marmarek this is the commit removing tinyproxy whitelisting updates-proxy: disable filtering at all · marmarek/old-qubes-core-agent-linux@69bb71b · GitHub

And relevant issue which removed whitelisting in tinyproxy: Updates tinyproxy blocks HTTPS deb/rpm sites · Issue #1188 · QubesOS/qubes-issues · GitHub


Relative discussion change:

Hey @sven! Seems like we contributed on the same issue back then. Hi there from the past, revisiting same issue, still opened issue from 2019: [Contribution] qubes-updates-cache · Issue #1957 · QubesOS/qubes-issues · GitHub

1 Like

Basically, the argument that led to the change was about complications of doing some mitm proxy to be able to translate https to http (inspect url in proxy) to https(egress from proxy).

So the logic applied was about blocking firefox in template, basically, and nothing else.

This goes back to cache-proxy idea, for which funding would probably be available. A practical, no user based manual translation, resukting in a drop in workable solution, without hacks (apt-cache like, but transparent to user) would probably resolve the problem, while bonus of having it by default, could cache templates package downloads to be reused across cloned templates.

Reminder: apt-cache-ng is currently for advanced users. We cannot ask from users to rewrite their repositories definitions…

Edit: this is the interesting post by @unman, followed by @marmarek who likes it: [Contribution] qubes-updates-cache · Issue #1957 · QubesOS/qubes-issues · GitHub

Same problem applies though. How to get the @%#%#$&# GPG keys in templatevm so new repositories can be added by users without compromising Template, and get rid of tinyproxy once and for all?

Maybe the wrapper needs to be around gpg keys download then. Having a tool for qubes to download armored/binary gpg keys loaded per gpg --homedir=/tpm/$(mktemp), list key, have the user confirm… Should be the wrapper using apt-cache-proxy logic?

@unman said in referred issue here that salt could be applied to sed the repositories deployed in templatevm on second run from dom0. So maybe this is what we really want?

Edit2: @sven: you seem to be the most active user of apt-cache-ng! Just finished reading issue 1957. Maybe you want to relaunch the discussion there on what is missing to be included? What the salt script should do? Collaborate with @unman for that to replace tinyproxy?

And the main question, sorry to be a bummer… How to properly wrap around a gpg public key download/verification wrapper so that the user can confirm long fingerprint prior of the whole shebang being written and trusted from user command?

Yes, that was a direct reason why whitelist was removed. But in general, the purpose of the proxy (instead of direct network access) is to limit what applications in a template can access the network. Not necessarily what part of the network they can access. The reasoning here is to give network access only to applications we trust to properly verify anything downloaded. This is briefly mentioned in the documentation at How to install software | Qubes OS but indeed could be further clarified.

As for @Sven “the author of the malicious script had to know that the target uses Qubes OS and therefore add code that would use proxy 8082” - this mechanism is not supposed to protect you against some malicious script that is already running in a template (however it got there). It’s simply impossible to do at this point in time. Even if template wouldn’t have any kind of network access, it would only mean that a malicious script cannot download additional malicious script. Not very consoling. And especially if a “malicious script” is already prepared to target Qubes OS specifically, it can be written to not require network access at all. The protection needs to be earlier - prevent getting a “random script” into a template in the first place. Admittedly, the curl-proxy idea is the opposite of it, but on the other hand, there are also significant arguments to have something like this (discussed in the other thread).


Users of apt-cacher-ng can limit what part of the network can be
accessed through the proxy.

apt-cacher-ng uses remapping to merge requests to a common cache.
The configuration files are in /etc/apt-cacher-ng, with the main file at
A standard config might look like this:

Remap-debrep: https://deb.debian.org http://deb.debian.org file:deb_mirrors.gz ; deb.debian.org
Remap-qubes: https://deb.qubes-os.org http://deb.qubes-os.org ; deb.qubes-os.org

The first section specifies the name of the merged cache - debrep
The second identifies URLs that will be merged - these can be specified
individually, or in a separate file - both methods are shown.
The third section is optional - it allows for redirection - whatever
repository is specified, the actual download will come from the
specified target server. (Again, this can be given individually or in a
target file containing lists of remote repositories.)

So in the debrep example, whatever repo is specified in the client request,
the actual download will come from deb.debian.org.
A request to a repository (or other source) which is not included in the
Remap definitions will be proxied individually.

It is possible to enforce the use of defined mirrors, by setting
ForceManaged: 1
This restricts use of the proxy to URLs matched in a Remap

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.