Consider removing build/infra tooling and requirements to another repository

[emkll]

In the current distribution method, we use git to deliver code to workstations. Pipfile(.lock) or requirements.txt (introduced in #318) are not needed to run the SecureDrop Workstation in a production context.

We should consider removing the logic and requirements to another repo, to avoid accidental install of dependencies in a production environment, as these are intended to be used in a dev-only context, and not reviewed as thoroughly as other dependencies we include.

Once we address #174 , this will no longer be an issue.

[conorsch]

Since we're moving away from S3 buckets for RPMs, switching to git-lfs, we'll shortly be able to drop the requirements* files altogether, given that they were used only for pulling in the AWS/S3 tooling.

Still, your point stands: we have more thinking to do about the "install" workflow for a fresh instance. I don't see a better method than git -> tar -> dom0 for the initial configuration of the dom0 yum/dnf repos. After that point, everything will be package-based, but we want to reduce the chances of misconfiguration even before that step.

We currently have two RPMs that this repo can create:

• securedrop-workstation-dom0-config
• qubes-template-securedrop-workstation{,-buster}

The latter is a special case, but the small amount of build logic we currently have (https://github.com/freedomofpress/securedrop-workstation/blob/e63773d059c97f9d9d712ac38593591c31cc4bc0/builder/build-workstation-template) could be moved to https://github.com/freedomofpress/qubes-template-securedrop-workstation.

For the salt package, I don't mind the logic living here, but perhaps we should create an RPM-equivalent of https://github.com/freedomofpress/securedrop-debian-packaging. That, or we could rename that repo to "securedrop-packaging" and handle all of it there.

[redshiftzero]

I don't see a better method than git -> tar -> dom0 for the initial configuration of the dom0 yum/dnf repos

i wonder if we could eventually get our packages included in qubes rpm repository (not sure what the process is for this)... otherwise until then yeah I agree

For the salt package, I don't mind the logic living here, but perhaps we should create an RPM-equivalent of https://github.com/freedomofpress/securedrop-debian-packaging. That, or we could rename that repo to "securedrop-packaging" and handle all of it there.

since there is a repo redirect when you rename a repo in github, i think that renaming securedrop-debian-packaging to securedrop-packaging and putting everything there makes sense (bonus: our CD bot has its credentials configured already in CI there). the redirect is nice because we are git cloning that debian packaging repo in a bunch of build jobs sprinkled across our securedrop projects that would be kinda annoying to update otherwise

[eloquence]

Since the issue was filed, the production release story has changed significantly, and prod users now have to manually configure the RPM repo in a separate VM, installing the workstation via RPM. This bypasses the risk of accidental installation of additional requirements. The infra tooling for the RPM server is no longer included in this repository. Closing.