Tails

#1 Updated by segfault 2018-01-22 18:41:19

• Parent task changed from Feature #14464 to Feature #15224

#2 Updated by segfault 2018-01-25 16:03:15

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

#3 Updated by intrigeri 2018-06-03 13:10:55

• 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 2018-06-03 18:22:07

• Status changed from Confirmed to In Progress

Applied in changeset commit:b6c2ab1a4e500407df9216bfd2e674254b343b38.

#6 Updated by segfault 2018-06-05 09:02:48

• 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 Feature #15244 for now

Ack.

#7 Updated by intrigeri 2018-06-05 09:53:11

• 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).

#9 Updated by segfault 2018-06-05 14:03:11

• 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 2018-06-05 14:50:17

• QA Check set to Ready for QA

#11 Updated by intrigeri 2018-06-05 15:05:47

• 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 2018-06-07 22:14:55

• 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 2018-06-10 12:33:24

• 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 2018-07-10 11:31:13

• Description updated

#15 Updated by segfault 2018-07-16 12:53:38

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

#16 Updated by segfault 2018-07-25 09:47:01

• 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 2018-07-28 10:03:19

• 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 2018-07-28 10:13:00

• 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 2018-07-30 14:26:27

• 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 2018-08-01 08:38:09

• 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 2018-08-01 19:09:02

• 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 Feature #15244 accordingly.