Tech Meeting Notes 2020 07 16
Topics:
- Backup strategies for SecureDrop Workstation
- Review and prioritization of discussion topics backlog
Facilitator:
- Allie
Notetaker:
- Allie, Mickael
Attendees:
- Allie, Conor, Erik, John, Kevin, Kushal, Mickael, Ro
Background:
Open questions:
- Is it useful to take a full system backup?
- What's the easiest way to backup and restore a VM?
Different backup options:
- config (required to generate the workstation) only
- config and app VMs (5.4GB)
- full system backup (40GB)
Dom0 backup only backs up the home directory: RPC policies are not preserved, and securedrop-admin --apply will always need to be run regardless
ro: potential improvement: move files from /usr/share/securedrop-dom0-config into a file backed up by dom0. Potientially have a export-config, to move the bundle the config somewhere into dom0 for it to be backed up
conor: we could even bundle the RPM
conor: 2 use cases:
- 2 laptops running in parallel
- disaster recovery scenario (reprovision from scratch)
erik: should we treat the workstation like a "thin client", ephemeral, that we should rebuild from scratch? In which case we should perhaps focus on a thin backup system (just the config). Are they use case where we want to store files in sd-app?
kev: it would make sense to have a solution that accomodates future needs, we should do it now rather than also do it later
mickael: Ro uncovered the case where the signning key was expired, so we could end up restoring to a case that is no longer useful. What if the whole base template has changed? Is that a case we want to handle? Backing up data is much lighter, less space is used, and a lot of system data is not useful to a user.
erik: here's how i see it: config written to tgz file, system backup for VMs with custom data. We discourage folks from backing up sd-app if they don't have to. if i want to restore, restore system backup, download RPM, restore configration and securedrop-apply
ro: if we offer a way to export what's useful in sd-app, (including submissions). The qubes backup tooling: - you can use an emergency restore procedure, but you are still backing up VMs and doesnt incentivize people to view raw files
erik: (in general) we should discourage people from backing up sensitive source data and encourage them to re-download submissions instead
ro: one more can of worms, something feels icky about backing an RPM and restoring from it. to mickael's point about templates and keys being out of date, i wonder if there's a path that would encourage people to not install from an old RPM
mickael: one of the more complicated things about the Qubes backup tooling: - built-in qubes encryption where you set up a passphrase - option to encrypt the device you are writing the backup to
mickael: one worry i have is that it could potentially be error prone to use Qubes tooling since it's pretty manual
conor: sd-devices has the tooling for luks-encryption
erik: we do have a lot of docs around using transfer/export devices
conor: because the backups are so large, you get into the 10s of gigs really quickly so it using a spinning platter is quickly needed
john: the Qubes API has a command to help automate this
erik: we could build out the tooling first and then find places in our own custom tooling to see what we can replace w API
- File issue in securedrop-workstation to describe lightweight backup tooling (config only) [Ro]
- Flesh out existing securedrop-workstation-docs issue to describe high level process [Ro]
Background:
(No notes on the discussion that took place, but basically allie asked questions about how to make our builds reproducible and the solution put forth is to use wheels that we build ourselves the way we do with the securedrop-workstation.)
- Kushal will facilitate the next SecureDrop Tech meeting on how to move forward on creating reproducible builds for securedrop
- Allie creates a facilitator guide: https://docs.google.com/document/d/1YcYbf0CKabryLDcuxmQCJcs4UI4MlCWgXXw_ZsiZoIs