Repo config for dom0 is duplicated in sys-firewall

[conorsch]

During review and testing of #700, @eloquence observed that the pubkey munging for dom0 repos applied to sys-firewall is redundant. See related history in #330.

In order to test the behavior, let's try:

• Branch from main
• Remove all sys-firewall logic for handling pubkey and repo configs
• Perform a clean install
• Reboot host machine
• Run GUI updater and confirm everything works well

Given that 1) we're careful to run rpm --import on the pubkey material inside dom0, and 2) the imported key material is shipped to sys-firewall via qubes-dom0-update, maintaining a separate copy of the pubkey in sys-firewall does appear to be unnecessary.

Let's revisit post 0.5.4 (#699), and honestly post key rotation (freedomofpress/securedrop#5923) to clean up.

[eloquence]

My read is that qubes-dom0-update packages up the contents of /var/lib/rpm, /etc/yum.repos.d, and /etc/yum.conf and ships those to the update VM (by default, sys-firewall):

https://github.com/QubesOS/qubes-core-admin-linux/blob/7c3a572efe89916dd5afc9c5431c8075ede3002d/dom0-updates/qubes-dom0-update#L205-L206

The corresponding qubes-dom0-updates.sh script that runs in sys-firewall configures the --installroot to use these extracted configuration files, superseding the files locally present in sys-firewall:

https://github.com/QubesOS/qubes-core-agent-linux/blob/cb25cce9e563823a0366aab53e5d2d362bba9f91/package-managers/qubes-download-dom0-updates.sh#L8

That includes the RPM database (which the keys are imported into), but it does not include /etc/pki. As far as I can tell, the gpgkey configuration in /etc/yum.repos.d/securedrop-workstation-dom0.repo in dom0 has no effect -- the reason that RPMs are verified successfully is that we're importing the key via rpm --import here:

securedrop-workstation/dom0/sd-dom0-files.sls

Line 32 in 9a55c9b

- name: sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-securedrop-workstation

(Updated)

Note, however, that because dom0 uses fedora-25, the RPM database has to be converted to a newer format after it is copied. This is done once every time sys-firewall is booted, and future changes to the RPM database in dom0 are not applied in sys-firewall. In other words, sys-firewall has to be rebooted before a qubes-dom0-update run to pick up a new key.

Our logic for copying the key into sys-firewall in https://github.com/freedomofpress/securedrop-workstation/blob/main/sys-firewall/sd-copy-rpm-repo-pubkey.sh (which is run via rc.local on VM boot) does ensure that dnf finds the key even if sys-firewall has not been rebooted. It does seem like a fairly complex way to accomplish that. Note that the copy in /etc/pki in dom0 is not used here, but rather the one in /srv/salt: https://github.com/freedomofpress/securedrop-workstation/blob/main/dom0/sd-sys-firewall-files.sls#L10