Hey,
thanks for the quick response!
Bastien Nocera:
> [...]
> What UI differences would be needed to handle those different types of
> encryption? I'm guessing none for handling encrypted disks, because the
> UI should be pretty much the same as for the existing LVM based
> encryption support.
Do you mean the LUKS encryption? In that case you would be correct, the
UI *should* be pretty much the same. But with VeraCrypt/TrueCrypt
encrypted volumes we have the difficulty that the volumes can not be
detected as such with absolute certainty, because, by design, they just
look like random data, and, in contrast to LUKS, have no cleartext
header. So we need to figure out a good way to indicate to our users
that a volume *could* be a VeraCrypt/TrueCrypt volume (because it looks
like random data).
There is also a possibility of confusion with dm-crypt plain and LoopAES
volumes, because those also look like random data. So we thought about
adding a dialog which lets the user specify the encryption type when
they want to unlock a (possibly) encrypted volume. We started discussing
implications of this on [1], and are currently leaning towards ignoring
dm-crypt plain and LoopAES and omitting an additional dialog.
[1]
https://labs.riseup.net/code/issues/6337
> How to deal with creating encrypted volumes, and even more so when
> talking about other types of encryption would need to be designed after
> you've figured out whether it makes any difference to the user, and how
> it would get integrated in UDisks.
We do not intend to add support for *creating* encrypted volumes, but
only unlocking/locking.
> I'd start with adding a transparent way to mount encrypted disks and
> volumes in UDisks, and see whether anything else is needed on top of
> that for your users, including explaining why particular types of
> encryption are better than others and under which circumstances.
I agree that we should start with adding the support to UDisks (which I
already started doing).
> I'm also not sure what "file containers" and "keyfiles" are, but it
> sounds like filesystem level encryption which would likely live in GIO
> and UIs on top of it, not in Disks or UDisks.
File containers are not filesystem level encryption, but encrypted
volumes which are stored in a file on the filesystem instead of a block
device. They could be handled by UDisks/Disks by first mapping a loop
device to the file container (for example using udisksctl loop-setup,
gnome-disk-image-mounter or the "Attach Disk Image..." option in Disks).
If a VeraCrypt/TrueCrypt volume is configured to use keyfiles, all
configured keyfiles need to be added in addition to the password (if
any) in order to unlock the volume (similar to LUKS keyfiles, which are
supported by UDisks/Disks, except that those replace the passphrase).
This also has nothing to do with filesystem level encryption.
Cheers!
