Support export to VeraCrypt-encrypted USB drives

[eloquence]

The export workflow prototyped in #259 exclusively implements support for LUKS, which is Linux-only. That's fine for admins who want to go from Qubes->air-gapped Tails, which may be necessary in many cases until we provide safe tooling inside Qubes for working with documents.

However, even during beta, there may be situations where journalists can safely export straight from Qubes to their regular workstation (e.g., TXT file submission), which most likely isn't a Linux device. We also may provide File Manager access to the export VM for advanced users, who may want to use tooling within Qubes to work with files.

VeraCrypt has good cross-platform support; we have published our own guide for using it, and it's supported within Tails. For these reasons, we should aim to add support for VeraCrypt volumes to the export workflow.

[eloquence]

Besides the passphrase, are there any VeraCrypt configuration options that we may need to support in the UI to successfully mount a VeraCrypt volume?

[eloquence]

VeraCrypt volumes can be mounted in cryptsetup since version 1.6.7. The version in Debian Stretch is 1.7.3, and I was successfully able to mount a VeraCrypt volume (formatted with exFAT filesystem) in a Debian Stretch VM in Qubes without extra software.

Be sure to use both the --type tcrypt and --veracrypt options.

Note that the official VeraCrypt implementation is required to create encrypted volume, and it is considered nonfree as it still includes old TrueCrypt code, which is under the TrueCrypt License:

https://www.gnu.org/licenses/license-list.en.html#Truecrypt-3.0

For this reason it's not included in official repositories for Debian, Ubuntu, etc. If users want to create the encrypted volume in Qubes, we'll likely have to direct them to download, verify and install it from the VeraCrypt website:

https://www.veracrypt.fr/en/Downloads.html

[ninavizz]

(cough) Bueller? I'm seein' a whole lotta Lux mentions in Slack aaaaand just wanna be checkin' in on this? I know, abreast the "please just get this darn flow to work" stuff. :)

/cc @eloquence @redshiftzero

[eloquence]

Per Slack discussions w/ Allie, Nina, Jen and Mickael today, we'll defer VeraCrypt support for now. Our recommendations for the pilot will be:

• print whenever possible (as we also recommend for the Tails workflow)
• for redaction and malware analysis, use your existing workflow on the air-gapped Tails SVS, which can handle LUKS.

VeraCrypt support is still a high priority, and will be considered post-Beta, along with integration of tooling for malware analysis and mitigation, and document/metadata redaction, directly within Qubes.

[eloquence]

Update from 2022-08-11 review with @tina-ux @nathandyer @L3th3 @eloquence:

• Still very much under active consideration!
• Report from most recent spike by @rocodes: [securedrop-export] [spike] Support Veracrypt securedrop-client#1730

[rocodes]

Commenting to describe the user-facing changes proposed at this stage that will be addressed in the 2 linked PRs above:

• Provide VeraCrypt support for already-unlocked drives (meaning, if a user inserts and unlocks a VeraCrypt drive in sd-devices, support exporting to it)
• Fix the bug where the password prompt screen is shown even if a drive is already unlocked

To accomplish this change there will be some behind the scenes changes in client and export that mean updating the results that sd-devices returns to sd-client via qrexec. So this will be a non-backwards-compatible change and will require coordinated release of new sd-client and sd-export packages. The good news is, these changes have been in the works for a while and will pave the way to a better export experience overall, and to other improvements in export that won't require a corresponding client release.

(This also paves the way for unlocking VeraCrypt drives via the client the same way we unlock LUKS drives, but there are more UX implications here in the case where the drive does not unlock properly, so I am in favour of deferring that part for now. We can support this later on in the client without requiring another sd-export release.)