`salt`: Initializing an `aur.chaos.cx`-using Archlinux (offline) template - Using the update proxy for `gpg` keys et al

[balin1]

I upgraded to 4.2 and am HAPPY to now have painless access to an Archlinux template.

I set out to include into my salted setup an additional template deriving from it but with the additional configuration to have access to the AUR as described here.

This process includes the requirements to a) retrieve a gpg key and b) install 2 packages in a repository-independent manner.
The corresponding *.sls currently looks like this:

{% if !salt['file.directory_exists']('/etc/pacman.d/gnupg') %}
Ensure proper initialization of the pacman-key infrastructure:
  cmd.run:
    - name: 'pacman-key --init'
{% endif %}

Import gpg key of aur.chaotic.cx:
  cmd.run:
    - name: 'pacman-key --recv-key 3056513887B78AEB --keyserver keyserver.ubuntu.com'
    - env:
      - http_proxy:  http://127.0.0.1:8082
      - https_proxy: https://127.0.0.1:8082

Locally sign the aur.chaotic.cx gpg key:
  cmd.run:
    - name: 'pacman-key --lsign-key 3056513887B78AEB'

Provide proxy settings for in-template installation of repository-independent packages:
  environ.setenv:
    - name: Proxy settings
    - value:
	    http_proxy:  http://127.0.0.1:8082
        https_proxy: https://127.0.0.1:8082

Repository-independently install packages providing the aur.chaotic.cx keyring and mirrorlist:
  pkg.installed:
    - sources:
      - chaotic-keyring:    https://cdn-mirror.chaotic.cx/chaotic-aur/chaotic-keyring.pkg.tar.zst
      - chaotic-mirrorlist: https://cdn-mirror.chaotic.cx/chaotic-aur/chaotic-mirrorlist.pkg.tar.zst

Reset proxy settings:
  environ.setenv:
    - name: Resetting proxy settings
    - value:
	http_proxy:  False
        https_proxy: False

Append aur.chaotic.cx definition to pacman.conf:
  file.replace:
    - name:                /etc/pacman.conf
    - pattern:             '\n\[chaotic-aur\]\s*\nInclude = /etc/pacman.d/chaotic-mirrorlist'
    - repl:                |

                           [chaotic-aur]
                           Include = /etc/pacman.d/chaotic-mirrorlist
    - flags:               ['MULTILINE']
    - append_if_not_found: True

Whatever I do this does not allow for the gpg key and packages to bw downloaded via the update proxy (sys-whonix) - I also fail to do so, BTW, from within the template using curl or wget as e.g. advised here.

Any hint on how to resolve this is highly appreciated.

[apparatus]

@balin1

I also fail to do so, BTW, from within the template using curl or wget as e.g. advised here.

Did you try to curl/wget some other sites for a test?
Check if tinyproxy is running in sys-whonix and check if qubes-updates-proxy service is enabled for sys-whonix:

Update templateVM through vpn-proxy

This suggests you haven’t enabled the proxy in the vpn qube - the service is tinyproxy Depending on how you set up the proxy, it’s also possible that your firewall configuration on the vpn-proxy is blocking traffic to/from tinyproxy. Try enabling the service with qvm-service and see if that works - if not, you’ll need to provide more information.

[balin1]

Thank you for the very interesting pointers.

In the course of the update to Qubes 4.2 and in the face of whonix-16’s approaching obsolescence I had switched sys-whonix to the testing template whonix-gateway-17. qubes-update-proxy was indeed not enabled, which is remedied now. It’s unclear whether this was an oversight of the upgrade process or whether this was alreadz broken in 4.1.

Additionally, tinyproxy in whonix-gateway-17-derived appVMs appear to have an issue to start the (enabled) service. systemctl status tinyproxy reports the process dead, as the start condition ConditionPathExists=/var/run/qubes-service/tinyproxy is not met. mkdiring the directory in sys-whonix renders the service startable.
Where would I configure this to permanent? mkdir in that location in the template does not survive a reboot.

I have yet to retrieve a file using curl or wget, but maybe I can ge there with further help from you?

Thanks again.

[apparatus]

The tinyproxy service is not needed, just check if the tinyproxy process is running.
The qubes-update-proxy service should start tinyptoxy.

[balin1]

ps -A indeed shows that tinyproxy runs in sys-whonix.

Trying to retrieve anything in the template using 127.0.0.1:8082 as the proxy keeps failing with lack of name resolution, though…

[apparatus]

In what template are you trying to curl/wget?

What’s the default update proxy for the templates in Qubes Global Config?

Check the logs in dom0 terminal:

journalctl

Maybe there’s a problem with policy as well.

[balin1]

In what template are you trying to curl/wget?

archlinux-aur

What’s the default update proxy for the templates in Qubes Global Config?

sys-whonix

Check the logs in dom0 terminal:…
Maybe there’s a problem with policy as well.

No:

Jan 03 17:37:31 dom0 qrexec-policy-daemon[2583]: qrexec: qubes.UpdatesProxy+: archlinux-aur -> @default: allowed to sys-whonix

[apparatus]

Can you try to curl/wget from default debian/fedora template for a test?

[balin1]

Same problem in debian-12

[apparatus]

Does network work in sys-whonix at all?
Set some qube to have sys-whonix as netvm and check if network will work in that qube.

[balin1]

The whonix-17-workstation-dvm uses sys-whonix as a netvm and firing up the an ephemeral vm using torbrowser works just fine.

[balin1]

… and using sys-whonix as netvm to something unrelated also works.

[apparatus]

Do you have qubes-update-proxy service enabled for sys-whonix?
Check it in dom0 terminal:

qvm-service sys-whonix

[balin1]

Yes.

[apparatus]

Did you restart sys-whonix after enabling qubes-update-proxy service?
Check the logs in sys-whonix, maybe there will be some info.

[balin1]

A system restart did not resolve this issue. Appropriate qubes-update-proxy setting for sys-whonix persisted through it and I validated a tinyproxy process to be running in sys-whonix.

[apparatus]

What if you try to use tinyproxy from sys-whonix itself?

curl.anondist-orig --proxy http://127.0.0.1:8082 https://check.torproject.org/

[balin1]

I think I got to the bottom of this:

1. https://cdn-mirror.chaotic.cx/chaotic-aur/chaotic-keyring.pkg.tar.zst can be downloaded using firefox in the open web as well as torbrowser through the tor gateway.
2. curling, however, does only work on the open web and when using TOR (via the update proxy) is subject to interference by cloudflare via a javascript challenge page.

I assume the latter is also interfering with pacman-key and such command line tools.

Do you see another option but switching the update proxy to sys-net rather than sys-whonix? Is an infrastructure imaginable that offers a free net (non TOR) proxy in addition to the TOR-ed default update proxy? Is sys-net not already offering that and under what IP might it be accessible?

[apparatus]

Try:

curl -L https://cdn-mirror.chaotic.cx/chaotic-aur/chaotic-keyring.pkg.tar.zst

[balin1]

The -L option I had fiured out and is indeed required when downloading from the free net. Through TOR it does not help. You download a html file indicating the challenge cloudfront injects rather than the package file itself.