Project

General

Profile

Feature #15244

Feature #14468: Add VeraCrypt support to Tails

Feature #15223: Iteration 2: Support unlocking VeraCrypt file containers in GNOME

Iteration 2: Upstream support for unlocking VeraCrypt file containers in Nautilus

Added by segfault over 1 year ago. Updated 5 days ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
-
Target version:
Start date:
01/25/2018
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Subtasks

Feature #15246: Iteration 2: Let upstream know we intend to support unlocking VeraCrypt file containers in NautilusResolved

Feature #15724: Iteration 2: Upstream 0002-gtkmountoperation-Support-TCRYPT-options.patch in GTKResolvedsegfault


Related issues

Related to Tails - Feature #15224: Iteration 2: Support unlocking VeraCrypt file containers in Nautilus Resolved 12/10/2017
Blocks Tails - Feature #14467: Upstream VeraCrypt support in GNOME Files In Progress 08/28/2017

History

#1 Updated by segfault over 1 year ago

  • Related to Feature #15224: Iteration 2: Support unlocking VeraCrypt file containers in Nautilus added

#2 Updated by segfault over 1 year ago

  • Subject changed from Upstream support for unlocking VeraCrypt file containers in Nautilus to Iteration 2: Upstream support for unlocking VeraCrypt file containers in Nautilus

#3 Updated by intrigeri over 1 year ago

  • Blocks Feature #14467: Upstream VeraCrypt support in GNOME Files added

#4 Updated by intrigeri about 1 year ago

  • Description updated (diff)

#5 Updated by intrigeri about 1 year ago

  • Status changed from Confirmed to In Progress

#6 Updated by segfault 12 months ago

  • Description updated (diff)

Updating the description: We don't want to upstream #15051 anymore, because the file association is now done by installing VeraCrypt Mounter.

#7 Updated by intrigeri 12 months ago

Updating the description: We don't want to upstream #15051 anymore, because the file association is now done by installing VeraCrypt Mounter.

Agreed. But what happens on GNOME without VeraCrypt Mounter? Don't we need a file association with GNOME disk image mounter there?

#8 Updated by segfault 12 months ago

intrigeri wrote:

Updating the description: We don't want to upstream #15051 anymore, because the file association is now done by installing VeraCrypt Mounter.

Agreed. But what happens on GNOME without VeraCrypt Mounter? Don't we need a file association with GNOME disk image mounter there?

We should discuss this. The problem I see is that gnome-disk-image-mounter will only trigger a user visible action (opening the unlock dialog), if a) the TCRYPT support is enabled (i.e. the file /etc/udisks2/tcrypt.conf exists), and b) the dconf automount setting is enabled. Else the volume will get associated to a loop device, but the user doesn't see anything about that. If they try to open it again, the volume will get associated with another loop device, and then a third, etc. That's not great UX IMO, so I'm not sure if this association should be made by default for all GNOME users.

Since some knowledge is required anyway to make this useful (i.e. create /etc/udsisks2/tcrypt.conf), the user will probably also be able to create the association by themselves via Properties -> Open With.

What do you think?

#9 Updated by segfault 12 months ago

  • Assignee changed from segfault to intrigeri
  • QA Check set to Info Needed

#10 Updated by intrigeri 12 months ago

  • Assignee changed from intrigeri to segfault

Thanks for the explanation!

segfault wrote:

What do you think?

I think we should come back to the /etc/udisks2/tcrypt.conf flag file topic. My understanding of https://github.com/storaged-project/udisks/pull/495#discussion_r182690124 (and our corresponding discussions) is that we implemented it this way in order to unblock the merge request, get the code into udisks, and allow you to proceed with the next steps, which was great, but maybe this should only be seen as a temporary hack that should be replaced by a better solution, given:

  • as you've explained here, this additional moving part blocks us from implementing some stuff properly in GNOME upstream;
  • on the Debian side of things, I've not convinced #15615 will work;
  • if this gets resolved neither in GNOME nor in Debian, some of our work won't be usable by users unless they somehow learn they need to do stuff on the command line as root.

Regarding what a proper solution would look like, vpodzime wrote, "Later we can implement some real configuration like blacklist and/or whitelist of devices that should be scanned, but for now this is an easy way to prevent potential confusing issues for users that don't use TC/VC". I have no idea how hard this is.

So I would like to know:

  • What user-facing VeraCrypt support features are broken or missing when the flag file does not exist, e.g. on a regular Buster system with all our GNOME patches in?
  • From a sponsor deliverable PoV, do these broken or missing features prevent us from reporting completion?
  • How costly do you expect the better solution to be?

Timing wise, I think all this can wait until after the 3.9 freeze, so let's put this on the back burner for now and focus on more pressing matters that block the merge of your branch into devel :)

#11 Updated by segfault 12 months ago

intrigeri wrote:

I think we should come back to the /etc/udisks2/tcrypt.conf flag file topic. My understanding of https://github.com/storaged-project/udisks/pull/495#discussion_r182690124 (and our corresponding discussions) is that we implemented it this way in order to unblock the merge request, get the code into udisks, and allow you to proceed with the next steps, which was great, but maybe this should only be seen as a temporary hack that should be replaced by a better solution, given:

  • as you've explained here, this additional moving part blocks us from implementing some stuff properly in GNOME upstream;

I think the file association is the only thing that is blocked - and I think it's a minor part, because it only works for volumes with the .hc/.tc extension, which very few users use (as shown by our survey).

  • on the Debian side of things, I've not convinced #15615 will work;

Yes, I'm aware that this is still unclear. I will get in touch with the maintainers after the 3.9 freeze.

  • if this gets resolved neither in GNOME nor in Debian, some of our work won't be usable by users unless they somehow learn they need to do stuff on the command line as root.

Correct.

Regarding what a proper solution would look like, vpodzime wrote, "Later we can implement some real configuration like blacklist and/or whitelist of devices that should be scanned, but for now this is an easy way to prevent potential confusing issues for users that don't use TC/VC". I have no idea how hard this is.

So I would like to know:

  • What user-facing VeraCrypt support features are broken or missing when the flag file does not exist, e.g. on a regular Buster system with all our GNOME patches in?

All of them, because all of the features base on udisks handling VeraCrypt volumes as encrypted volumes.

  • From a sponsor deliverable PoV, do these broken or missing features prevent us from reporting completion?

I don't think so, because I don't think we promised that the VeraCrypt support would be enabled by default in upstream.

  • How costly do you expect the better solution to be?

I'll need some time to think about that, but right I have more pressuring issues to work on, so I will probably do that after the 3.9 freeze.

#12 Updated by intrigeri 11 months ago

  • Target version changed from Tails_3.9 to Tails_3.10.1

#13 Updated by segfault 9 months ago

  • Target version changed from Tails_3.10.1 to Tails_3.11

#14 Updated by CyrilBrulebois 7 months ago

  • Target version changed from Tails_3.11 to Tails_3.12

#15 Updated by anonym 6 months ago

  • Target version changed from Tails_3.12 to Tails_3.13

#16 Updated by CyrilBrulebois 4 months ago

  • Target version changed from Tails_3.13 to Tails_3.14

#17 Updated by CyrilBrulebois 2 months ago

  • Target version changed from Tails_3.14 to Tails_3.15

#18 Updated by intrigeri about 2 months ago

  • QA Check deleted (Info Needed)

#19 Updated by CyrilBrulebois 13 days ago

  • Target version changed from Tails_3.15 to Tails_3.16

Also available in: Atom PDF