(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! _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
