Tails

#7 Updated by intrigeri 2018-08-02 00:43:14

> Updating the description: We don’t want to upstream Feature #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 2018-08-02 09:17:53

intrigeri wrote:
> > Updating the description: We don’t want to upstream Feature #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?

#11 Updated by segfault 2018-08-07 20:37:48

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 Feature #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.

#20 Updated by intrigeri 2019-08-18 13:13:21

I see that all the subtasks have been resolved (congrats again!). Is there anything left to do here?

(The discussion above does not count as Feature #15615 was refocused to take it into account and solve those problems some day.)

If not, we can close this ticket, then Feature #14467, Feature #14464, Feature #15223, and… Feature #14468!

#21 Updated by segfault 2019-08-18 18:46:06

> I see that all the subtasks have been resolved (congrats again!). Is there anything left to do here?

There is still Bug #15667 (I just changed its parent ticket to this ticket instead of Feature #14468), which has one follow-up merge request left:
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1018.

I had hoped that this would be merged soon, because it only addresses some UI issues raised by Allan Day after the other MR was merged. But there hasn’t been any activity since I opened it 3 weeks ago. So I would be OK with removing it from the list of MRs on Bug #15667 and then closing the ticket.