DX: cannot "make dev" on fresh qubes machine

[conorsch]

• I have searched for duplicates or related issues

Description

When setting up a dev env for the Workstation, on Qubes, a first-run of make dev from dom0 yields a dependency error, related to the securedrop-workstation-keyring package.

Steps to Reproduce

0. Ensure no SDW packages are installed on the Qubes machine (purging all of them should be sufficient to test)
1. Follow the dev docs on SDW dev env until the make dev step
2. Run make dev and observe error; see exact error logs below.

Expected Behavior

I expect the dev-facing scripts to configure the dom0 environment and proceed with creating SDW-specific VMs.

Actual Behavior

Prior to any sdw-admin commands running, the make dev invocation fails, complaining about a missing dependency on securedrop-workstation-keyring.

Comments

error message from `make dev` failure

Deploying Salt config...
Uninstalling any previous RPM versions...
0 files removed
No match for argument: securedrop-workstation-dom0-config
No packages marked for removal.
Dependencies resolved.
Nothing to do.
Complete!
Installing RPM at /home/conor/securedrop-workstation/rpm-build/RPMS/noarch/securedrop-workstation-dom0-config-
1.6.0rc1-1.fc37.noarch.rpm ...
Qubes OS Repository for Dom0                       0.0  B/s |   0  B     00:00
Errors during downloading metadata for repository 'qubes-dom0-cached':
  - Curl error (37): Couldn't read a file:// file for file:///var/lib/qubes/updates/repodata/repomd.xml [Could
n't open file /var/lib/qubes/updates/repodata/repomd.xml]
Error: Failed to download metadata for repo 'qubes-dom0-cached': Cannot download repomd.xml: Cannot download r
epodata/repomd.xml: All mirrors were tried
Ignoring repositories: qubes-dom0-cached
Error:
 Problem: conflicting requests
  - nothing provides securedrop-workstation-keyring needed by securedrop-workstation-dom0-config-1.6.0rc1-1.fc
37.noarch from @commandline
(try to add '--skip-broken' to skip uninstallable packages)
make[1]: *** [Makefile:60: install-rpm] Error 1
make[1]: Leaving directory '/home/conor/securedrop-workstation'
make: *** [Makefile:33: dev] Error 2
[conor@dom0 securedrop-workstation]$

The error message make sense: the RPM package securedrop-workstation-dom0-config sets a dependency on securedrop-workstation-keyring [sic], but the make dev process builds and installs a keyring package that's called securedrop-workstation-keyring-dev:

[conor@dom0 securedrop-workstation]$ dnf list | grep -i securedrop
Errors during downloading metadata for repository 'qubes-dom0-cached':
  - Curl error (37): Couldn't read a file:// file for file:///var/lib/qubes/updates/repodata/repomd.xml [Could
n't open file /var/lib/qubes/updates/repodata/repomd.xml]
Error: Failed to download metadata for repo 'qubes-dom0-cached': Cannot download repomd.xml: Cannot download r
epodata/repomd.xml: All mirrors were tried
Ignoring repositories: qubes-dom0-cached
securedrop-workstation-keyring-dev.noarch         0.1.0-1.fc37                      @qubes-dom0-cached

In terms of solutions, we can either:

1. conditionally modify the RPM spec for securedrop-workstation-dom0-config to include the -dev suffix; or
2. drop the suffix from the securedrop-workstation-keyring package, so the existing dependency is honored.

My preference is slightly toward 2 for consistency, but I reckon the team may have already decided that the -dev suffix is worthwhile, in which case one would be the answer.

[conorsch]

Naturally it's quite possible I made a mistake in following the docs, so don't hesitate to ask for another repro: I have secondary hardware that's still clean enough to suffice in further testing, of this or other issues.

[zenmonkeykstop]

see the first block of commands in https://workstation.securedrop.org/en/stable/admin/install/install.html - it will add the qubes-contrib repo and the keyring package.

I'm not sure what was behind the decision to have a separate -dev RPM exactly but IMO it makes sense in terms of reducing the chance of a prod user ending up adding the test key/repo with the associated security implications.

[deeplow]

In terms of solutions, we can either:

1. conditionally modify the RPM spec for securedrop-workstation-dom0-config to include the -dev suffix; or
2. drop the suffix from the securedrop-workstation-keyring package, so the existing dependency is honored.

My preference is slightly toward 2 for consistency, but I reckon the team may have already decided that the -dev suffix is worthwhile, in which case one would be the answer.

This may have been an oversight. I see some potential disadvantages with 1.: require conditional build logic, which was part of what the keyring was trying to address in the first place. Personally I'm not opposed to having build variants for dev and staging. But just staging as context for the original motivation, as I understand it.

What we've been doing is basically install the production keyring from qubes-contrib. But theoretically, we also have the -keyring available in our repos. So one option is to have the make {dev,staging} commands install the prod keyring as well. This should be OK as -keyring-dev has higher precedence, I think.

[conorsch]

Spoke about this at length with both @deeplow and @legoktm, and we've got consensus that it's simply an oversight to have make dev not work out of the box. Will focus on the minimal solution to get it working again.

In particular, it was illuminating for me to understand that the dom0 yum repos are now layered, same as the apt repos are within the Debian VMs, depending on env config—so that the prod keys and repo are always present, and the other repos only conditionally.