Hi, thanks for the quick reply! I re-add the tails-dev mailinglist to Cc.
Kai Lüke: > Seems I misunderstood while reading, so you already have code. Correct. Sorry if I didn't make that clear enough. I will still answer your previous email below. In case you already want to have a look at the current status (which only supports basic unlocking/locking of "standard" VeraCrypt/TrueCrypt volumes), the code lies in my forks of the udisks and gnome-disk-utility repos [1][2] in branch "support-tcrypt". [1] https://github.com/segfault3/udisks [2] https://github.com/segfault3/gnome-disk-utility > If your way of identifying encrypted partitions works good enough (which > is funny because the partition is not really hidden then) you can ignore > my sentences on presenting those device contents. Standard TCRYPT volumes are not supposed to be hidden (in contrast to the hidden volumes, of which we don't know yet if we want to support them or not), they are only supposed to be indistinguishable from random data. We identify TCRYPT candidates by performing a chi-squared test [3] on each volume, which is a fast test for randomness. We had a discussion about this here [4]. [3] https://en.wikipedia.org/wiki/Chi-squared_test [4] https://mailman.boum.org/pipermail/tails-dev/2017-October/011754.html > From the GNOME Disks point of view it would be good if things work > mostly the same, e.g. UDisks.Block.CryptoBackingDevice and > udisks_client_get_cleartext_block. ACK, I did use the same interfaces that are used for LUKS. As a result, besides renaming, I only had to modify 3 lines in GNOME Disks to integrate unlocking and locking support for "standard" VeraCrypt and TrueCrypt volumes. > Am 14.11.2017 um 17:36 schrieb Kai Lüke: >> 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 Yep, this is what I did. >> * add the UDisks2.Encrypted interface in UDisks if the block device >> content could not be identified Also did that, except that I only add the UDisks2.Encrypted interface if the device passes the chi-squared test, to have fewer false-positives. >> * 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") Exactly, this is the problem of indicating to the user that the volume *could* be a TCRYPT candidate, which I mentioned in my previous email. I'm not sure how to best solve this. Currently I set the id_type long_name to "Possibly Encrypted" and the short_name to "Encrypted?". But we actually have a UX person in our team who will take a look at the whole workflow after we evaluated the survey data and decided what exactly we want to do. >> * GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in >> UDisks (currently lacking for LUKS as well) Right. To be sure I didn't miss anything: The only place in GIO/GVFs which unlocks encrypted volumes is the gvfs-monitor, right? >> and a way to select a keyfile from GNOME Shell is needed. Yeah, I think this would be the hard part, because the GNOME Shell password dialog doesn't allow other windows to be focussed, so I guess we would have to patch that. >> One could also decide to explicitly >> ignore them there and only offer unlocking via GNOME Disks. This is a decision which will be easier once we evaluted the survey data, because we asked our users whether they use keyfiles. >> 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 the survey evaluation shows that we should support file containers (which I expect), then we will have to find a solution to allow the user to unlock a container via Nautilus. UX-wise it would be best to associate all file containers with the unlocking application (e.g. gnome-disk-image-mounter), but this would require us to detect whether a file is a TC/VC container. I don't think it would be a good idea to perform the chi-squared test on every file encountered by Nautilus. An easy solution would be to rely on the containers having the .tc/.hc extensions. We will get data on this by the survey, but I'm in favor of already thinking about alternatives. I think it would be nice to be able to use gnome-disk-image-mounter in order to trigger gvfs-udisks2-volume-monitor to unlock the "mounted" (i.e. loop-device associated) image. But currently gvfs-udisks2-volume-monitor does not attempt to unlock images which get associated with loop-devices. Maybe we could change this. Currently, after opening the file container with gnome-disk-image-mounter, the user would have to start Disks and unlock the file there, which is not good UX IMO. >> 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. We do not plan to support creating new TC/VC containers, and I didn't even know that zulucrypt can do this (thanks for the hint!). I find the idea tempting, maybe I will work on that at some point. >> 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. I agree. >> The best is to open issues for each needed part in every involved >> project, Ok. I will now open one ticket for adding simple TC/VC unlocking support in Disks. For UDisks such a ticket already exists. I will then add more tickets for other features once we decided that we want them. >>I will review the parts for GNOME Disks and also have time to >> work on something from January/Feburary if needed. Great! Cheers! _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/devkit-devel
