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

Host securedrop-workstation RPM for installation in dom0 #157

Closed
conorsch opened this issue Oct 4, 2018 · 1 comment · Fixed by #260
Closed

Host securedrop-workstation RPM for installation in dom0 #157

conorsch opened this issue Oct 4, 2018 · 1 comment · Fixed by #260
Assignees

Comments

@conorsch
Copy link
Contributor

conorsch commented Oct 4, 2018

During partial review of #155, we discovered that various developers have divergence in their debian-9 templates, which caused different behaviors of crucial features such as mimetype handling. Our manual testing should not be subject to variation caused by local customizatoins.

The work by @emkll in #115 provides us with an RPM of the workstation template. We should host this RPM in a yum repo, so that it's available for installation in dom0. Doing so will ensure a stable baseline for development efforts, and force a clean configuration for use in prod installs.

While the build process for the RPM is a bit onerous, we are not required to update the template RPM in order to ship changes: we can pull in package updates via an FPF-controlled apt repository. We should still periodically update the RPM to avoid package drift and minimize setup and testing time, but most release-related changes will likely occur via deb packages.

This work should come after the work described in #156.

@conorsch
Copy link
Contributor Author

conorsch commented Nov 8, 2018

Discussed the next steps here with @msheiny on a call; summarized:

  1. RPMs will be hosted in the existing S3 "dev" bucket (see here for example https://github.com/freedomofpress/securedrop-debian-packaging/blob/893cae8f109c3ec913af02f4bb827ed9225c4582/wheelsurls.txt)
  2. We'll use a subdir inside that dev bucket, called e.g. rpms. We'll likely want a nested structure, e.g. rpms/dom0/archive and rpms/dom0/repo.
  3. Signed RPMs (Add instructions for verifying integrity of sources and binaries #192 for details on signing) will be uploaded to the "archive" subdir.
  4. Scripts will be used to generate the repo metadata in the "repo" subdir; the RPM will be copied over. (We may have to reupload the RPM to get it into the repo; that's not ideal, since the template RPM is several GB, but acceptable for alpha.)

Step 4 requires a bit of scripting and tooling. @msheiny has thoughts on that, so he'll take lead on implementing. Then @emkll / myself can review that work to upload RPMs can thereby close this issue.

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

Successfully merging a pull request may close this issue.

2 participants