README

        qubes-updates-cache for Qubes R4.0

Updating my various templates was getting a little annoying with all the
redundant network traffic, so I set up a qubes-updates-cache modeled on
qubes-updates-proxy, using standalone Squid (no Apache etc. involved).


        Security considerations

1. The remote network can distinguish if a file is requested via qubes-updates-
   cache (Squid) or via qubes-updates-proxy (tinyproxy). The former's user base
   is smaller, making attacks (where valid signatures for malicious packages
   can be produced somehow) more targeted even over Tor, i.e. less likely to be
   detected.
2. Clients can determine if a package is installed on another client on the
   same physical computer by requesting it and measuring cache response time.
3. (The following is also true of qubes-updates-proxy:) For Tor users, the
   remote network has some insight about what's installed on the same physical
   computer, because there is no Tor circuit isolation between update requests
   from different clients. This can be prevented by waiting at least 10 minutes
   (or sending NEWNYM) between updating different clients.


        Installation

Create a new VM (which should be based on a distribution that packages Squid
with OpenSSL support, e.g. Fedora rather than Debian), ensure it has the netvm
you want, and enable the qubes-updates-cache service:

    [dom0] $ qvm-create --template fedora-XX --label red squidp
    [dom0] $ qvm-prefs squidp netvm sys-whonix  # or keep the default
    [dom0] $ qvm-service --enable squidp qubes-updates-cache

Copy this directory (containing the README you're reading) into your new
VM's template, carefully inspect its contents there and:

    [squidp's template] # dnf install squid
    [squidp's template] # ./install
    [squidp's template] # poweroff

If squidp's netvm is torifying (e.g. sys-whonix), you can transparently rewrite
many repository URLs to .onion:

    [squidp] # mkdir -p /usr/local/etc/qubes-updates-cache/urls
    [squidp] # ln -s /etc/qubes-updates-cache/urls/10-onion.bash.EXAMPLE \
           /usr/local/etc/qubes-updates-cache/urls/10-onion.bash

If your Squid build's HTTPS support is disabled (e.g. on Debian-based
distributions) you need to deactivate the rewrite-to-HTTPS rules:

    [squidp] # mkdir -p /usr/local/etc/qubes-updates-cache/urls
    [squidp] # >        /usr/local/etc/qubes-updates-cache/urls/20-https.bash

Edit the qubes.UpdatesProxy policy file and change all occurences of
"target=sys-net" or "target=sys-whonix" to "target=squidp".

    [dom0] # vim /etc/qubes-rpc/policy/qubes.UpdatesProxy

Finally, for Whonix gateway/workstation clients, you currently need to bypass
the safety mechanism that checks for a torified update proxy:

    [dom0] $ qvm-service --enable whonix-ws whonix-secure-proxy

That's it! Up to 4 GiB of package updates will be cached to squidp's volatile
storage in /var/lib/qubes/vm-updates/. If you want to keep them across reboots:

    [squidp] # mkdir -p /rw/config/qubes-bind-dirs.d
    [squidp] # echo 'binds+=( /var/lib/qubes/vm-updates )' \
                    >/rw/config/qubes-bind-dirs.d/qubes-updates-cache.conf