Tails

#1 Updated by segfault 2018-05-22 16:42:51

• Deliverable for set to 299

#4 Updated by intrigeri 2018-06-03 13:08:58

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

Given udisks is not a GNOME project and is thus not affected by the July 30 freeze (for GNOME 3.30) I say let’s focus on upstreaming GNOME stuff until July 30 and then come back to polishing the udisks bits.

#5 Updated by segfault 2018-08-26 08:41:31

• Assignee changed from segfault to intrigeri

Idea we came up with during our meeting: Maybe the TCRYPT support should only be enabled by default for Desktop systems / systems that have GNOME installed,

#6 Updated by intrigeri 2018-08-27 04:44:34

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

#7 Updated by intrigeri 2018-09-05 17:27:25

• Priority changed from Normal to High

#8 Updated by intrigeri 2018-10-16 18:14:52

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

So, the goal here is to make our work on VeraCrypt support in GNOME useful for GNOME users outside of Tails, without having to guess they need to create a /etc/udisks2/tcrypt.conf file as root.

Our options seem to be, in the order I think we should try them:

• Don’t do the check for every udev change event on every block device, which should solve most of upstream’s concerns. udisks_linux_block_update does not know what kind of change happened so we cannot filter on this. We could only do the check if the /etc/udisks2/tcrypt.conf flag file exists (i.e. its meaning becomes “inconditionally do the check on all block devices”) OR the block device is on a removable drive (the main use case and a pretty efficient filter) OR (ID_FS_USAGE is empty AND the device has no partition table). Then, for those without the flag file, i.e. most users:
  • The “udisks will not be able to unlock a given TCRYPT volume with a chance of n / 65536, where n = number of filesystems with a 2 byte magic number that are supported by udev” problem only exists for non-removable drives, which is a minority case already.
  • Performance cost is zero in the majority of cases, i.e. no removable drive is plugged and ID_FS_USAGE is non-empty for all devices except drives that have a partition table.
• Enable the detection by shipping /etc/udisks2/tcrypt.conf in some existing GNOME package, e.g. gnome-disk-utility.
  • Pros: enables the feature where it makes most sense because it is better supported, and where we’ve successfully validated the setup, i.e. GNOME desktops. Does not affect anyone else e.g. non-desktop systems.
  • Cons(?): it’s a bit more complicated than it sounds. It might be cheap to do this in Debian (if it’s not rejected because we should do this upstream), but then only users of Debian and its derivatives benefit from it; to fix that, we need to suggest other major distros to do the same, and then the cost raises a lot because we know very little about how to interact with them. So overall, it’s probably cheaper to propos this to GNOME Disks upstream first.
• Enable the detection by shipping /etc/udisks2/tcrypt.conf in a new udisks2-tcrypt package. Probably won’t fly because one-file packages are frowned upon. Same issue as the GNOME Disks option: it needs to be done in all major distros. And then, we still need to convince a higher-level package to Recommend this one, otherwise we did not gain much in practice.

segfault:

• Can you tell me (spending the least possible amount of time on it) how much work it would take to implement my first option above in udisks_linux_block_update? Any difficulties to be expected? (I’m not a C person but I can copy’n’paste’n’adjust; AFAICT we already have access to the parent drive and to ID_FS_USAGE so it looks doable.)
• Does that option make sense to you? If yes, and if you can’t foresee particular difficulties, I’ll give it a try.

#12 Updated by segfault 2018-10-23 22:33:23

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

#13 Updated by intrigeri 2018-10-31 16:16:41

• Subject changed from Iteration 1: Clarify whether we can upstream a `udisks2-tcrypt.deb` to Debian to Try to have VeraCrypt support enabled by default in udisks
• Status changed from Confirmed to In Progress
• Assignee changed from segfault to intrigeri
• % Done changed from 0 to 10
• Parent task changed from Feature #15214 to Feature #14468
• QA Check deleted (Info Needed)
• Deliverable for deleted (299)

I’ll propose my preferred plan to upstream today. It would be nice to have but technically this is not a sponsor deliverable.

#15 Updated by intrigeri 2018-10-31 17:07:37

• Description updated

#16 Updated by intrigeri 2018-10-31 17:08:17

• % Done changed from 10 to 20

#17 Updated by intrigeri 2018-11-19 15:53:35

• Tracker changed from Bug to Feature
• Subject changed from Try to have VeraCrypt support enabled by default in udisks to Have VeraCrypt support enabled by default in udisks
• Priority changed from High to Normal
• Target version changed from Tails_3.11 to Tails_3.12
• Type of work changed from Communicate to Code

Initial feedback from upstream about my proposal was positive, woohoo :) I’ll schedule time to give it a try, hopefully in December. I’ll handle it as volunteer work with a relaxed timeline and I’m very happy if someone else takes it over: I’ve not written more than trivial patches in C for 15+ years.

#18 Updated by intrigeri 2019-01-02 05:03:45

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

December didn’t work. Next step: book some time for this.

#19 Updated by intrigeri 2019-03-11 09:35:32

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

I’ll try to start this during the upcoming FT sprint, if segfault is around.

#20 Updated by intrigeri 2019-04-07 09:32:31

• Target version deleted (Tails_3.14)

#21 Updated by intrigeri 2019-11-17 05:56:16

• Assignee deleted (intrigeri)
• Parent task deleted (Feature #14468)

Unparenting because the “Add VeraCrypt support to Tails” part is done: we enable VeraCrypt detection in udisks. This is about enabling such support by default in udisks upstream.

A year has passed and I did not manage to make time for this. I doubt I’ll do any better in the upcoming year so I’m unassigning myself.

I’m a bit tempted to put this on the FT’s plate, because:

• I’m slightly concerned that we’re (almost?) the only ones toggling this support on and exercising the corresponding code paths, so chances are that if there’s any regression in this area, we’ll only notice once we start porting Tails to the next version of Debian. Usually we do so early enough to give us time to fix stuff upstream and let it migrate to Debian testing before the freeze but that’s not a given.
• There are a few folks who can write C muuuuch more efficiently than me there.

Thoughts, opinions?