Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide on dev/staging provisioning strategy compatible with securedrop-workstation-keyring #1232

Open
Tracked by #1230
rocodes opened this issue Jan 15, 2025 · 0 comments

Comments

@rocodes
Copy link
Contributor

rocodes commented Jan 15, 2025

(Converted to issue from the release checklist)
With securedrop-workstation-keyring providing the yum prod .repo file and release signing key, the dev/staging provisioning will need to be adjusted in order to maintain compatibility with existing make targets.

Ideally, the workstation-keyring package will be solely in charge of the file securedrop-workstation.repo in /etc/yum.repos.d/, and will not be dynamically provisioned with a staging repo config at provisioning time, since that could lead to confusing behaviour: RPM will check that the file is present, but will not overwrite its contents if it is, so the best case is for staging/dev to provision a file with a different name (eg securedrop-workstation-staging.repo), probably removing the prod .repo file so as not to confuse dom0 updates, and additionally importing the staging key into the rpm database.

@rocodes rocodes changed the title Decide on dev/staging provisioning strategy. (ideally no dev-facing changes; ideally a change that installs a different workstation .repo file such as securedrop-workstation-staging.repo with the staging config, as the case may be, instead of editing the one .repo file dynamically, as we do now.) Decide on dev/staging provisioning strategy compatible with securedrop-workstation-keyring Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant