Feature #15615

Have VeraCrypt support enabled by default in udisks

Added by segfault 2018-05-22 16:42:35 . Updated 2019-11-17 05:56:16 .

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2018-05-22
Due date:
% Done:

20%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

In the udisks pull request, it was suggested that the TCRYPT support is only enabled when a config file is present, and that this config file can then be packaged separately to allow users to easily activate TCRYPT support by installing this extra package.

intrigeri raised concern about such a package being accepted into Debian, because tiny packages are frowned upon. We asked the udisks2 maintainers whether this is a real possibility but they did not reply. And anyway, this would only solve the problem on Debian and its derivatives.

Current discussion with upstream: https://github.com/storaged-project/udisks/issues/589


Subtasks


History

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

  • Deliverable for set to 299

#2 Updated by segfault 2018-06-01 17:32:46

Status: Wrote an email to the udisks2 Debian maintainers 10 days ago but didn’t get a reply yet.

#3 Updated by intrigeri 2018-06-01 23:10:41

> Status: Wrote an email to the udisks2 Debian maintainers 10 days ago but didn’t get a reply yet.

Suggestion: sum up the problem to them and the practical effects of either option to actual human users. Pointing them to the full discussion on GitHub is a good start but they might not find it worth their time to read it all, so if you pre-process it in a way that makes it easier for them to answer you, you’ll have greater chances to get an answer at all :)

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

#9 Updated by intrigeri 2018-10-16 18:17:54

Forgot to say:

  • My plan is to first submit the plan to udisks upstream, before implementing anything.
  • Sorry it took me 1.5 month to start working on it.
  • My goal is to start the discussion upstream this month and if they agree by the end of the month, submit a first PoC/RFC PR (I know I win the acronym density contest, eh). Everything else can wait a bit more since it’s not gonna make it into GNOME 3.30.x anyway.

#10 Updated by segfault 2018-10-16 21:12:13

intrigeri wrote:
> * 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.)

I think all of these properties should be easily accessible in udisks_linux_block_update.

> * Does that option make sense to you? If yes, and if you can’t foresee particular difficulties, I’ll give it a try.

I did not spend a lot of thought on whether these conditions are the most useful ones to narrow down potential TCRYPT candidates, and I won’t do so today.

#11 Updated by intrigeri 2018-10-17 07:36:03

> I did not spend a lot of thought on whether these conditions are the most useful ones to narrow down potential TCRYPT candidates, and I won’t do so today.

Sure. Depending on how much time I have for this today, either I’ll go ahead and ask upstream what they think about it, or it’ll have to wait a week (which will give you some time to think about it if you want).

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

#14 Updated by intrigeri 2018-10-31 17:06:47

intrigeri wrote:
> I’ll propose my preferred plan to upstream today.

Done: https://github.com/storaged-project/udisks/issues/589

#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

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?