Feature #15478

Revisit GVfs goals for iteration 1

Added by intrigeri 2018-03-30 11:31:57 . Updated 2018-05-28 16:50:28 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Target version:
Tails_3.7
Start date:
2018-03-30
Due date:
% Done:

0%

Feature Branch:
Type of work:
User interface design
Blueprint:

Starter:
Affected tool:
Deliverable for:
299

Description

As explained by segfault on Feature #15218#note-8:

  • supporting via GVfs the simplest possible kind of VeraCrypt volumes all kinds of volumes except ones using keyfiles is easy (or even done)
  • supporting via GVfs all other kinds of VeraCrypt unlocking using keyfiles is much more expensive than expected

One option would be to stop here and require users to use GNOME Disks to unlock non-trivial VeraCrypt devices.

Files

DialogWithOpenDisksButton.png (250290 B) segfault, 2018-05-02 18:48:15
DialogOpenDisksLabelRephrased.png (234644 B) segfault, 2018-05-04 14:44:26

Subtasks

Related issues

Blocks Tails - Feature #15218: Iteration 1: Support unlocking VeraCrypt partitions in GVfs Resolved 2018-01-22

History

#1 Updated by intrigeri 2018-03-30 11:32:13

  • blocks Feature #15218: Iteration 1: Support unlocking VeraCrypt partitions in GVfs added

#2 Updated by intrigeri 2018-03-30 11:32:55

Next step: segfault describes what happens for a user with volumes we would not support via GVfs; and then segfault and sajolida update our plans based on this new cost/benefit data.

#3 Updated by intrigeri 2018-03-30 11:33:23

  • Priority changed from Normal to Elevated

#4 Updated by intrigeri 2018-03-30 11:37:03

This impacts the cost of Feature #15253 (related to Feature #15037) because it can change the number of packages we need to patch and maintain until we’re based on Buster.

#5 Updated by intrigeri 2018-03-30 11:42:29

  • Priority changed from Elevated to High

#6 Updated by intrigeri 2018-04-06 10:39:38

  • blocks #15252 added

#7 Updated by segfault 2018-04-11 12:16:43

> Next step: segfault describes what happens for a user with volumes we would not support via GVfs

If GVfs opens the unlock dialog for a non-supported VeraCrypt volume (either because the device was plugged in, or because the user clicked on the device in the GtkPlacesSidebar), the unlock dialog will currently look exactly the same as for LUKS devices, and the user will be left confused, because they can’t choose the required parameters for their volume (i.e. PIM, keyfiles, hidden volume, etc.).

To fix this, we should display a message in the unlock dialog, e.g. “If this volume requires additional parameters (keyfiles, PIM, etc.), use GNOME Disks to unlock it”. Maybe even better, we could create a link or button which opens Disks with the correct volume selected. The latter requires that Disks is always installed if GNOME Shell is (because the unlock dialog is part of GNOME Shell), but at least in Debian gnome-disk-utility is a dependency of gnome-core, so that might work.

A problem with this is that it probably still requires us to patch all the libraries to even know whether the volume is TCRYPT or LUKS in the unlock dialog. It would be simpler modifications, but it would still be a lot of work to upstream all of these packages.

Before we take a decision on this, I would like to test whether my assumptions are correct, which I couldn’t do yet because I’m struggling with getting GNOME Shell to build (again). I will keep trying and report back here.

#8 Updated by segfault 2018-04-11 12:20:43

segfault wrote:
> A problem with this is that it probably still requires us to patch all the libraries to even know whether the volume is TCRYPT or LUKS in the unlock dialog. It would be simpler modifications, but it would still be a lot of work to upstream all of these packages.

A workaround would be to display this message for both TCRYPT and LUKS, but I doubt that we could upstream this, because it would be a regression for LUKS users (an unhelpful message, which could also be confusing, because LUKS also has keyfiles, but they are neither supported by the GVfs unlock dialog nor Disks).

#9 Updated by segfault 2018-04-30 15:32:42

  • Description updated
  • Assignee changed from segfault to sajolida

Update: I got everything except keyfiles to work now. But it seems really hard to implement unlocking with keyfiles via the GVfs dialog.

So now we should discuss if it would be acceptable UX-wise to not allow users to unlock volumes with keyfiles via the GVfs dialog, but only via GNOME Disks.

We could add a label like “If this volume requires keyfiles, use the Disks application to unlock it.”, and a “Open Disks” button to the dialog, which opens Disks with the volume selected when clicked. What do you think sajolida?

#10 Updated by segfault 2018-05-02 18:48:44

> We could add a label like “If this volume requires keyfiles, use the Disks application to unlock it.”, and a “Open Disks” button to the dialog, which opens Disks with the volume selected when clicked. What do you think sajolida?

I implemented this, except that the volume is not selected in Disks automatically, because gnome-shell doesn’t know which block device the dialog is opened for - which means that we would have to pass it via a new argument from GVfs, which would change the function signature and require changes in all software using the ShellMountPasswordDialog. We could discuss this upstream I guess.

I add a screenshot of how it currently looks like.

#11 Updated by sajolida 2018-05-04 14:13:33

  • Assignee changed from sajolida to segfault

Hey! I lost track a bit of your progress but I’ve very happy to see that you managed to patch the GVfs dialog. Congrats!

I like your solution regarding keyfiles.

I would shorten the message from:

If you want to use keyfiles with this volume, use the Disks application to unlock it.

To:

To unlock a volume that uses keyfiles, use Disks.

(GNOME Help refers in some places to “the Disks application” but to “Disks” only in some others. In our documentation so far we’ve refered consistently to “Disks” only.)

Also, your screenshot made me notice that there is an inconsistency in upstream GVfs between “passphrase” (first sentence) and “password” (text field).

In Disks they use “passphrase” when creating a new encrypted volume. In VeraCrypt they use “password”. So I’m not sure what to do…

Would it be an option to consistently use “passphrase” everywhere in our patches? As a way of being consistent withing GNOME at least…

#12 Updated by segfault 2018-05-04 14:44:39

sajolida wrote:
> Hey! I lost track a bit of your progress but I’ve very happy to see that you managed to patch the GVfs dialog. Congrats!
>
> I like your solution regarding keyfiles.

Cool!

> I would shorten the message from:
>
> […]
>
> To:
>
> […]

Done, thanks!

> (GNOME Help refers in some places to “the Disks application” but to “Disks” only in some others. In our documentation so far we’ve refered consistently to “Disks” only.)
>
> Also, your screenshot made me notice that there is an inconsistency in upstream GVfs between “passphrase” (first sentence) and “password” (text field).

That’s correct, but it’s not introduced by us. Both the first sentence and the text field are from the original dialog.

> Would it be an option to consistently use “passphrase” everywhere in our patches? As a way of being consistent withing GNOME at least…

I don’t think we use either term in any of our patches (user visibly at least).

#13 Updated by segfault 2018-05-04 14:49:32

  • Assignee changed from segfault to sajolida

sajolida wrote:
> I like your solution regarding keyfiles.

So we agree that this an acceptable solution and we can close this ticket, right?

#14 Updated by sajolida 2018-05-04 15:24:00

Yeap!

#15 Updated by sajolida 2018-05-04 16:07:38

  • Status changed from Confirmed to Resolved
  • Assignee deleted (sajolida)

#16 Updated by intrigeri 2018-05-28 16:50:28

> So we agree that this an acceptable solution and we can close this ticket, right?

Perhaps it’s worth encoding your conclusions (and perhaps the reasoning behind it) on the blueprint?
I’m slightly worried that we’ll have a hard time finding it here whenever we’ll need it in the future.
Your call!