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

Rebuild qubes-template-securedrop-workstation for production #424

Closed
emkll opened this issue Jan 23, 2020 · 6 comments · Fixed by #439 or freedomofpress/securedrop-yum-prod#1
Closed

Comments

@emkll
Copy link
Contributor

emkll commented Jan 23, 2020

The test apt key is baked into our base image [1]. In order to prepare for the beta, we will need to rebuild the template using a production apt server.

This requires either:

  • Deploy certain packages to the prod apt server prior to running the build
  • Adding some build-only logic to use a pre-prod server to build the template

[1] https://github.com/freedomofpress/qubes-template-securedrop-workstation/blob/master/securedrop-workstation/04_install_qubes_post.sh#L39

@emkll emkll added this to the 0.2.0beta milestone Jan 23, 2020
@emkll
Copy link
Contributor Author

emkll commented Jan 30, 2020

The rationale here is that we want to use a single template in all environments. As discussed in standup today, we can sign the resulting .rpm artifact with both test and prod keys: After a build, they will be signed with the test key and pushed to the test apt server. Once testing is successful, we can sign this artifact with the release key, and push to the prod apt server for release.

I would recommend we proceed as follows:

  1. (optional) Build new kernel, test locally
  2. Replace logic in https://github.com/freedomofpress/qubes-template-securedrop-workstation/blob/master/securedrop-workstation/04_install_qubes_post.sh#L42 to point to production apt server
  3. Build template

For 2., we can either (keeping in mind the goal would be to reduce (eliminate) the possibility of a prod install using non-prod repos/artifacts) :
a. Upload the kernel images (+ metapackage and config package) to the prod server, and use the prod server to install the kernel images
b. Use the apt-test server for bootstrap, and then remove the apt-test server after installing the kernel (replacing with prod apt server + keys). We will need to carefully promote the kernel images (+metapackage and config packages as well)

While method a. provides consistency at the expense of complexity, I would be inclined to go for option b., for the beta.
@conorsch @redshiftzero any preferences here ?

@conorsch
Copy link
Contributor

Great discussion, @emkll. For now, let's proceed with installing "test" packages in the template build logic, and signing the resulting template RPM with the test key (since CI-built artifacts were used). That'll keep the wheels turning for the current sprint.

We should aim to provide production packages in advance of beta QA in the following order:

  1. Tag suitable SDW deb packages
  2. Build prod-ready SDW deb packages, upload to prod apt server
  3. Update template build logic to use prod config by default (although a separate target for "make staging-template" or similar would be useful!)
  4. Sign prod-only template RPM with prod key
  5. Upload to prod endpoints

Then we can proceed with ~2 weeks of QA using prod infra and and bump versions as necessary. Tagging @redshiftzero since I'm suggesting we push packages to prod endpoints before the final beta go-live date. Doing so will force us to become familiar with the new release machinery in advance of the go-live date. We'll almost certainly update a few package versions during QA.

@redshiftzero
Copy link
Contributor

@conorsch: @emkll and I just discussed this, I'm onboard with the approach of publishing packages to the prod apt server for bootstrapping the prod template (even if that means multiple rounds of packages since we get practice with the release flow as you point out)

@conorsch
Copy link
Contributor

conorsch commented Feb 14, 2020

Re-opening to track remaining tasks:

  • sign new rpm with test key
  • upload new rpm to yum-test
  • confirm make dev works well (requires purging templates manually)
  • sign rpm with prod key
  • upload rpm to yum-prod

@conorsch
Copy link
Contributor

Updated checklist above: still outstanding are prod-signed RPMs, which will land in the prod repo (https://github.com/freedomofpress/securedrop-workstation-prod-rpm-packages-lfs/) in draft form this week.

Before we can finalize the "prod" setup, we'll need to rebuild all deb packages from prod-signed tags, then rebuild the dom0 config RPM. At that point, the make prod target, as well as the manual verification workflow recommended in the README, should pass completely.

@conorsch
Copy link
Contributor

Status update: @redshiftzero is working on prod-signing tags for the SDW deb packages. Once that's done, we can release them to prod apt.

@emkll Plans to start a draft/WIP PR for the prod template, which will be blocked on final merge until we the Workstation debs in the prod repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment