Rename VMs per https://github.com/freedomofpress/securedrop-workstation/issues/285

[eloquence]

Blocked on freedomofpress/securedrop-workstation#407

The file extension for export/print archives is still called .sd-export

Status

Ready for review

Testing

I have fully tested these changes in Qubes. All rename-related PRs should be reviewed together. See test plan in freedomofpress/securedrop-workstation#407

Packaging PR: freedomofpress/securedrop-builder#128

[eloquence]

If I understand correctly, due to the file rename build-buster here will fail until freedomofpress/securedrop-builder#128 is merged, and build-buster-securedrop-client on that PR will fail until this is merged. Let me know if there's a way to get CI to green before merge, otherwise I think it's expected and both should be merged together.

[emkll]

It just occurred to me that any breaking change to packaging will require a version bump for the securedrop-client package. Not only will it be useful to distinguish the cutover between new and old named vms, but CI for the packaging repo checks out the latest released tag (see https://github.com/freedomofpress/securedrop-debian-packaging/blob/vm-rename/.circleci/config.yml#L8). Because the MANIFEST.in changed in this PR, and has associated changes in the .install file in the securedrop-workstation-packaging pr (https://github.com/freedomofpress/securedrop-debian-packaging/pull/128/files#diff-0956cfc06b5206c5b7049630f2dbacddR8), we will need to bump versions for securedrop-client to ensure a smooth transition and passing ci.

Example:

• For securedrop-client: 71763b7
• for securedrop-debian-packaging: https://github.com/freedomofpress/securedrop-debian-packaging/pull/117/files

Once this PR is merged, the reviewer can cut a new tag, and re-run the ci in securedrop-debian-packaging, which should pass.

[eloquence]

Preparatory bits done:

• Packaging repo change: freedomofpress/securedrop-builder@2519b98
• Client repo change: f37e4db

[emkll]

Changes LGTM, merging per freedomofpress/securedrop-workstation#407 (comment)