Protect production users from setting up a dev or staging environment in error using production RPM

[zenmonkeykstop]

Currently the RPM includes the test signing key and repo config - setting up a dev or staging environment involves changing the env setting involves changing one value in config.json and running sdw-admin --apply. This increases the risk that users may configure a test environment in error for a system intended for production.

There are a few options for guardrails we could put in place:

• [ ] https://github.com/freedomofpress/securedrop-workstation/issues/1053
• [ ] Build separate RPMs for dev/staging and production, containing the correct keys in each case. (see #1031)
• [ ] dev and staging envs will have a copy of the source available in dom0 - we could overwrite the RPM-provided key and repo config in the prep-dev script invoked via make {dev,staging} prior to running sdw-admin --apply

We should discuss and pick one.

[zenmonkeykstop]

My personal preference is for the last option - it seems like the simplest approach and is general in case we move away from Salt altogether.

[rocodes]

Just to expand a bit on the options here:

• 1053 alone would not solve the issue of "don't ship test artifacts in the prod rpm" (which I agree we should not do, even if they're dormant.)

• The second option was not well-received, and I think the concerns are fair, but I'll expand a bit more on it in a followup comment, just so we all have the same mental picture of what this option is
• The 3rd option would mean leaning harder on make clone and making sure that dom0 always has an up to date copy of the code. I think this is okay ish, not ideal
• Another option like the 3rd option is to create a dev/staging package that is supplementary, signed with the test key, and contains .repo and .asc. Users would first install this package, and/then the dom0-config package, then run apply. In the fancy final form, there could be an orchestration package that basically just runs apply and that depends on having a keyring and a dom0 config package installed. But that's maybe getting ahead of ourselves.
  • This option is maybe in line with our thinking about a separate key + repo package living in qubescontrib.

So I guess a slightly-more-friendly/packaged version of option 3 would be my vote--basically something that is long-term stable and doesn't get overwritten every time we run the updater, would be my criteria.

[rocodes]

rpm build options (option 2)

Initially I proposed conditional builds with macros ( if %buildcondition ...), where the conditions were on by default and represented prod settings. Now that we are managing those settings with systemd, what I would suggest instead for this "different RPMs" option would be to build workstation-dom0-config-dev, worksation-dom0-config-staging, and workstation-dom0-config-prod, based on the same .spec file and with most sections of the .spec file shared, and with the only differences in these packages being the .repo and signing pubkey file for easy diffing (so explicitly disallowing other forms of customization between RPMs).

That would look something like

# securedrop-workstation-dom0-config.spec
Name:       securedrop-workstation-dom0-config
Version:    0.10.0
Release:    1%{?dist}
Summary:    SecureDrop Workstation

[snip]

%install
[snip - unchanged from current]

%install dev
install -m files/test-key.asc %{buildroot}/etc/pki/rpm-gpg/RPM-GPG-SECUREDROP-WORKSTATION
install -m files/securedrop-workstation-dev.repo %{buildroot}/etc/yum.repos.d/securedrop-workstation-dom0.repo

%install staging
install -m files/securerop-release-key-2021.asc %{buildroot}/etc/pki/rpm-gpg/RPM-GPG-SECUREDROP-WORKSTATION
install -m files/securedrop-workstation-staging.repo %{buildroot}/etc/yum.repos.d/securedrop-workstation-dom0.repo

[snip]
%files
[unchanged]

%files dev
/etc/pki/rpm-gpg/RPM-GPG-SECUREDROP-WORKSTATION
/etc/yum.repos.d/securedrop-workstation-dom0.repo

%files staging
/etc/pki/rpm-gpg/RPM-GPG-SECUREDROP-WORKSTATION
/etc/yum.repos.d/securedrop-workstation-dom0.repo

[snip]

It's basically a lite version of the keyring package, without it being a separate keyring package. I'm not attached to this and it's not perfect, but it's one idea.

[rocodes]

Last idea: I think we could also combine the options, eg:

• provision supplementary "staging" and "dev" packages signed by our test key that provision test/staging files to a separate pillar env
• In provisioning, look for files in those directories to provision, or fall back to prod configuration (default always) if none available

[legoktm]

I think it makes sense to discuss this as part of the SDW install story. Depending on how users get the key initially during bootstrapping affects how we split out the prod/test keys. For example, if we ship an external keyring package in qubes-contrib for prod users, it makes sense to tell dev users to manually install the test key.

[zenmonkeykstop]

I think it makes sense to discuss this as part of the SDW install story. Depending on how users get the key initially during bootstrapping affects how we split out the prod/test keys. For example, if we ship an external keyring package in qubes-contrib for prod users, it makes sense to tell dev users to manually install the test key.

We won't get to the separate keyring package for the initial 4.2 release, I guess this means we can defer this question for now.

[rocodes]

After thinking about it (and also related issues such as https://github.com/freedomofpress/securedrop-workstation/issues/1178) I am leaning towards something like this:

• separate keyring/repo bootstrap package where the prod keyring package and rpm repo config are packaged as an rpm.
  • The prod rpm could be hosted on qubes-contrib, our signed variant flavours (qa, staging) could be hosted in our yum repos, and the dev one could be built locally. We could also use package dependencies to ensure that sdw-admin --apply depends on the right bootstrap package. (see the type of discussion in https://github.com/freedomofpress/securedrop-workstation/issues/1015, some circularity to be resolved but separate bootstrap pkg may help).
• pillar data for fedora version, debian version, and other variables, per https://github.com/freedomofpress/securedrop-workstation/issues/1178, https://github.com/freedomofpress/securedrop-workstation/issues/1053