On Tue, 2017-11-14 at 17:36 +0900, Kai Lüke wrote: > Hello, > > of course there is more than one way to do it, but this is how I quickly > thought about this: > > * use the cryptsetup support for locking/unlocking in libblockdev and > make it work from the UDisks2.Encrypted interface > * add the UDisks2.Encrypted interface in UDisks if the block device > content could not be identified Please note that a TC/VC device can easily be identified as something else -- having the first few random bits accidentally being recognized as some other format's signature.
> * GNOME Disks needs some changes in terms of how to present such a > device in a different way from normal LUKS devices since for most people > the block device is indeed empty and it would be confusing to confront > everybody with failing decryption actions (maybe call the action > "attempt to unlock hidden volume") > * GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in > UDisks (currently lacking for LUKS as well) and a way to select a > keyfile from GNOME Shell is needed. One could also decide to explicitly > ignore them there and only offer unlocking via GNOME Disks. Correct me if I'm wrong, but key files in TC/VC are a little bit different concept than key files in LUKS where they are simply files containing the passphrase (binary) data. > > This should give support for existing containers/partitions. I would > treat containers as normal filesystem images. When opened from nautilus > they are mounted read-only by default with gnome-disk-image-mounter → > need to expose writeable mount there. > > If desired at some point: Formatting a partition/block device with > veracrypt needs to be added to libblockdev (maybe cryptsetup can't do it > but 3rd party binaries like zulucrypt-cli). This has to be made > available from UDisks2.Block.Format() > Then, to create a new container, one would open GNOME Disks, create an > empty disk image and format it. > Currently the format dialog offers no encryption option for NTFS/FAT → > add veracrypt here. The dialog page with other filesystems could also > expose veracrypt if that is really needed. > > Please give some feedback if this rough plan fits the needs. Not all can > be planned in advance but discussing things now raises the chances to > consider some corner cases before code lands. > The best is to open issues for each needed part in every involved > project, I will review the parts for GNOME Disks and also have time to > work on something from January/Feburary if needed. Sounds great to me otherwise. Thanks for working and willing to work on this, everybody! -- Vratislav Podzimek Senior Software Engineer Kernel Storage Red Hat Czech, Brno _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/devkit-devel