Unlocking TrueCrypt/VeraCrypt volumes in GNOME

[segfault <segfault riseup net>]

(Resending this because my first email awaits moderator approval,
because I was not a member of this list)

Hi,

this is about the ongoing effort to integrate support for TCRYPT
(TrueCrypt-compatible and VeraCrypt) volumes in GNOME. It will allow
GNOME users to use the platform-independent TCRYPT format in the same
way as the already well integrated LUKS format.

For more information about this see the blueprint [1] and the thread on
the gtk-devel-list [2].

[1] https://tails.boum.org/blueprint/veracrypt/#index5h2
[2]
https://mail.gnome.org/archives/gtk-devel-list/2018-January/msg00037.html
(see also replies in February)

We have added support to unlock TCRYPT volumes in libblockdev, udisks,
and finally via GNOME Disks.
All of those were merged already.

As a follow-up, I created merge requests to add VeraCrypt support in:

 - GLib https://gitlab.gnome.org/GNOME/glib/merge_requests/120
 - GVfs https://gitlab.gnome.org/GNOME/gvfs/merge_requests/4
 - GNOME Shell https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126

The purpose of this new set of merge requests is to allow users to also
unlock TCRYPT volumes via the GVfs udisks volume monitor. This monitor
opens a modal dialog in GNOME Shell when an encrypted device is
attached, in order to allow the user to unlock it. GNOME already
provides this useful feature to LUKS users and we want to make it
available to TCRYPT users as well.

I also created a merge request for GTK+:

https://gitlab.gnome.org/GNOME/gtk/merge_requests/200

The purpose of this patch is to display file containers (both unlocked
and locked, but already attached to a loop device) in the
GtkPlacesSidebar. The reason for this is that, according to our survey
[3], a lot of TCRYPT users (76%) use file containers, so they would
benefit from the containers being available in the places sidebar
(similarly to encrypted removable devices).

[3] https://tails.boum.org/blueprint/veracrypt/#survey

We've conducted moderated user testing of the current state of our work,
which validated our approach. It also helped us identify a couple areas
that would benefit from some polishing. But we don't think these issues
are blockers to merge our work before the upcoming feature freeze and we
have time allocated to implement these improvements in time for the
GNOME 3.29 string freeze.

Cheers!