Project

General

Profile

Feature #15051

Feature #14468: Add VeraCrypt support to Tails

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

Feature #15224: Iteration 2: Support unlocking VeraCrypt file containers in Nautilus

Iteration 2: Associate .hc/.tc extension with VeraCrypt

Added by segfault over 1 year ago. Updated 11 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
12/12/2017
Due date:
% Done:

90%

Feature Branch:
segfault:feature/14481-TCRYPT-support-beta
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

Files with the extension .hc/.tc should be associated with an application that can unlock VeraCrypt file containers. Fortunately, there is already the gnome-disk-image-mounter application as part of gnome-disk-utility, which simply associates a loop device with the specified file. This triggers the GVfs volume monitor to automatically prompt the user to unlock the volume (once we finished #15044). So all we should have to do is associate the .hc/.tc extension with gnome-disk-image-mounter.

Update: "we should change the association to VeraCrypt Mounter instead of gnome-disk-image-mounter (and extend VeraCrypt Mounter to handle being called with file paths as argument), because without auto-mounting it only attaches the file to a loop device, but doesn't open an unlock dialog." (#14481#note-62)


Related issues

Related to Tails - Bug #15734: TCRYPT containers mounted via gnome-disk-image-mounter are read-only Resolved 07/16/2018

Associated revisions

Revision b6c2ab1a (diff)
Added by segfault about 1 year ago

Associate .tc/.hc file extension with gnome-disk-image-mounter (refs: #15051)

Revision 9492210d (diff)
Added by segfault about 1 year ago

Change how TCRYPT MIME types are associated (refs: #15051)

Revision df2c4322 (diff)
Added by segfault about 1 year ago

Associate TCRYPT MIME type with gnome-disk-image-mounter (refs: #15051)

History

#1 Updated by segfault over 1 year ago

  • Parent task changed from #14464 to #15224

#2 Updated by segfault over 1 year ago

  • Subject changed from Associate .hc/.tc extension with VeraCrypt to Iteration 2: Associate .hc/.tc extension with VeraCrypt

#3 Updated by intrigeri about 1 year ago

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

shared-mime-info is not a GNOME project and is thus not affected by the July 30 freeze (for GNOME 3.30). Let's focus on upstreaming GNOME stuff until July 30 and then come back to this.

#4 Updated by segfault about 1 year ago

  • Status changed from Confirmed to In Progress

#5 Updated by intrigeri about 1 year ago

The initial, buggy implementation was fixed in 63a6757feaa82e1b910b3bf048b27ba3abcb0f6d which will be good enough for the beta but I have some questions/requests before we can merge this into devel:

  • Short-term: why not use config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list instead? I'll skip commenting on the code until this is addressed (the solution I'm suggesting does not require writing any code :)
  • Long-term: this should be done in the relevant upstream project so I'm adding a note about this on #15244 for now

#6 Updated by segfault about 1 year ago

  • Assignee changed from segfault to intrigeri

intrigeri wrote:

  • Short-term: why not use config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list instead? I'll skip commenting on the code until this is addressed (the solution I'm suggesting does not require writing any code :)

I chose the directory based on the descriptions I found in the mime apps spec (and the XDG Base Directory Specification). The best choices seem to be /usr/local/share (i.e. $XDG_DATA_DIRS, used for "distribution-provided defaults"), and /etc/xdg (i.e. $XDG_CONFIG_DIRS, "sysadmin and ISV overrides"). But those either already exist or get overwritten by the 10-tbb hook. For $HOME/.local/share (i.e. $XDG_DATA_HOME) the spec says it's deprecated, so that seems like a bad choice. On the other side, I guess this deprecated directory will still be supported for compatibility for a long time, and using it does avoid using yet another hook. So I'm not sure what to prefer. What do you think?

  • Long-term: this should be done in the relevant upstream project so I'm adding a note about this on #15244 for now

Ack.

#7 Updated by intrigeri about 1 year ago

  • Assignee changed from intrigeri to segfault

intrigeri wrote:

  • Short-term: why not use config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list instead? I'll skip commenting on the code until this is addressed (the solution I'm suggesting does not require writing any code :)

I chose the directory based on the descriptions I found in the mime apps spec (and the XDG Base Directory Specification). The best choices seem to be /usr/local/share (i.e. $XDG_DATA_DIRS, used for "distribution-provided defaults"), and /etc/xdg (i.e. $XDG_CONFIG_DIRS, "sysadmin and ISV overrides"). But those either already exist or get overwritten by the 10-tbb hook. For $HOME/.local/share (i.e. $XDG_DATA_HOME) the spec says it's deprecated, so that seems like a bad choice. On the other side, I guess this deprecated directory will still be supported for compatibility for a long time, and using it does avoid using yet another hook. So I'm not sure what to prefer. What do you think?

Thanks for the pointers and the extensive research \o/

Background:

  • It's one of these cases where it's tricky because we never quite know whether we're wearing a sysadmin hat (generally that's the cheapest), a vendor hat (generally more costly but leaves room for customization by users and Tails derivatives), or something in between. Ideally we would override Debian's defaults while leaving room for 1. customization by derivatives; 2. customization by users of Tails or of a Tails derivative.
  • We already have 2 different ways to configure such stuff (config/chroot_local-hooks/10-tbb and config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list) and I'd rather not add a third one… even if it uses a better location than the 2 existing ones.

Long term, I think /usr/local/share/applications/{gnome-,}mimeapps.list is probably the best choice: it leaves room to derivatives to override our prefs via /etc/xdg and to users via their home directory. I don't understand why you say it "already exist or get overwritten". I see no such file in Tails so do you mean its content would get fully overriden by the file 10-tbb creates in /etc/xdg?

Short term, I say let's stick to config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list as long as it works: we'll have automated tests for this feature so if it ever breaks in $next_Debian we'll notice way before it affects our users, and then we can come back to this, clean stuff up and move to a better location (possibly /usr/local/share). I wouldn't spend much time on this now anyway because whatever we do on this ticket will get reverted as soon as it's upstreamed and in Debian, so better keep it as simple as possible (and adding a line to /etc/skel/.local/share/applications/mimeapps.list is much simpler than writing a shell script – you don't want me to nitpick on your shell code and I don't want to see you waste much time learning how to write shell that's up to our usual standards).

#8 Updated by segfault about 1 year ago

intrigeri wrote:

Background:

  • It's one of these cases where it's tricky because we never quite know whether we're wearing a sysadmin hat (generally that's the cheapest), a vendor hat (generally more costly but leaves room for customization by users and Tails derivatives), or something in between. Ideally we would override Debian's defaults while leaving room for 1. customization by derivatives; 2. customization by users of Tails or of a Tails derivative.
  • We already have 2 different ways to configure such stuff (config/chroot_local-hooks/10-tbb and config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list) and I'd rather not add a third one… even if it uses a better location than the 2 existing ones.

Ah, I didn't see that we already ship config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list.

Long term, I think /usr/local/share/applications/{gnome-,}mimeapps.list is probably the best choice: it leaves room to derivatives to override our prefs via /etc/xdg and to users via their home directory. I don't understand why you say it "already exist or get overwritten".

I thought that was the path of the GNOME defaults, but actually those are in /usr/share, so I agree, /usr/local/share seems like the best choice.

Short term, I say let's stick to config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list as long as it works: we'll have automated tests for this feature so if it ever breaks in $next_Debian we'll notice way before it affects our users, and then we can come back to this, clean stuff up and move to a better location (possibly /usr/local/share). I wouldn't spend much time on this now anyway because whatever we do on this ticket will get reverted as soon as it's upstreamed and in Debian, so better keep it as simple as possible (and adding a line to /etc/skel/.local/share/applications/mimeapps.list is much simpler than writing a shell script – you don't want me to nitpick on your shell code and I don't want to see you waste much time learning how to write shell that's up to our usual standards).

ACK.

#9 Updated by segfault about 1 year ago

  • Assignee changed from segfault to intrigeri

I pushed a commit to use config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list.

#10 Updated by intrigeri about 1 year ago

  • QA Check set to Ready for QA

#11 Updated by intrigeri about 1 year ago

  • Assignee changed from intrigeri to segfault
  • QA Check changed from Ready for QA to Info Needed

segfault wrote:

I pushed a commit to use config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list.

I can't find it. Where did you push? (Please set the feature branch field.)

#12 Updated by segfault about 1 year ago

  • Assignee changed from segfault to intrigeri
  • QA Check changed from Info Needed to Ready for QA
  • Feature Branch set to feature/15051-TCRYPT-MIME-type

I pushed it to the beta now. I thought that I had already pushed it but the commit didn't contain the right changes - not really sure what happened, I guess I screwed up the merge with your branch.

I now also created a feature branch based on devel.

#13 Updated by intrigeri about 1 year ago

  • Assignee changed from intrigeri to segfault
  • % Done changed from 0 to 70
  • QA Check deleted (Ready for QA)

segfault wrote:

I pushed it to the beta now.

Looks good! I did not test it but I assume you've built an ISO and tested it yourself already. I've pushed this to feature/14481-TCRYPT-support-beta in the official tails.git so that people who download nightly builds can test it too.

Please:

  • update the comment in config/chroot_local-hooks/11-associate-tcrypt-extensions, that became incomplete with your change
  • add a note somewhere (e.g. in that same comment, with a "XXX:Buster" marker) about reverting these changes once they're not needed anymore, i.e. most likely in Tails 4.x

I now also created a feature branch based on devel.

Thanks. That won't be needed though: this change in isolation is not terribly useful so I expect it'll be merged along with the rest of your work (currently: feature/14481-TCRYPT-support-beta). Besides, I'd rather not have the same commit with different IDs in two different places.

#14 Updated by intrigeri 12 months ago

  • Description updated (diff)

#15 Updated by segfault 12 months ago

  • Related to Bug #15734: TCRYPT containers mounted via gnome-disk-image-mounter are read-only added

#16 Updated by segfault 11 months ago

  • Assignee changed from segfault to intrigeri
  • QA Check set to Ready for QA

On the 14481 feature branch, I changed the file association to VeraCrypt Mounter and extended VeraCrypt Mounter to handle being called with file paths as argument.

#17 Updated by intrigeri 11 months ago

  • Feature Branch changed from feature/15051-TCRYPT-MIME-type to segfault:feature/14481-TCRYPT-support-beta

segfault wrote:

On the 14481 feature branch, I changed the file association to VeraCrypt Mounter and extended VeraCrypt Mounter to handle being called with file paths as argument.

Adjusting metadata accordingly.

#18 Updated by intrigeri 11 months ago

  • Assignee changed from intrigeri to segfault
  • QA Check changed from Ready for QA to Dev Needed

Please merge current devel into your branch otherwise it won't build on Jenkins (merge conflict) and I can't test it.

#19 Updated by segfault 11 months ago

  • Assignee changed from segfault to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:

Please merge current devel into your branch otherwise it won't build on Jenkins (merge conflict) and I can't test it.

Done.

#20 Updated by intrigeri 11 months ago

  • Assignee changed from intrigeri to segfault
  • % Done changed from 70 to 90
  • QA Check changed from Ready for QA to Info Needed

Tested, works fine!

intrigeri wrote:

  • add a note somewhere (e.g. in that same comment, with a "XXX:Buster" marker) about reverting these changes once they're not needed anymore, i.e. most likely in Tails 4.x

When checking whether my previous review was fully handled, I found this note. I think this request of mine is obsolete: VeraCrypt Mounter will probably ship its file association snippet forever so there's nothing we need to remove in Tails 4.x => I guess we're good (assuming our bits will take priority over the GNOME bits associating these files to the GNOME disk image mounter).

segfault, please double-check my reasoning and close as resolved if you think I'm correct.

#21 Updated by segfault 11 months ago

  • Status changed from In Progress to Resolved
  • QA Check deleted (Info Needed)

intrigeri wrote:

Tested, works fine!

intrigeri wrote:

  • add a note somewhere (e.g. in that same comment, with a "XXX:Buster" marker) about reverting these changes once they're not needed anymore, i.e. most likely in Tails 4.x

When checking whether my previous review was fully handled, I found this note. I think this request of mine is obsolete: VeraCrypt Mounter will probably ship its file association snippet forever so there's nothing we need to remove in Tails 4.x => I guess we're good (assuming our bits will take priority over the GNOME bits associating these files to the GNOME disk image mounter).

segfault, please double-check my reasoning and close as resolved if you think I'm correct.

That is correct, the file association is now done by the /usr/local/share/mime/packages/veracrypt-mounter.xml file, which we don't want to upstream, because it is installed along with VeraCrypt Mounter. I updated #15244 accordingly.

Also available in: Atom PDF