Tails

#2 Updated by 110100111011 2017-09-29 01:37:56

Hey, I’m just wondering, why is there a “development cost” associated with veracrypt support? What exactly do you mean with “adding VeraCrypt support to Tails”? Tails already supports Veracrypt:

cryptsetup --veracrypt open --type tcrypt path name

You can mount any veracrypt volume with that. Sure, a GUI for that would be nice, but this feature sounds like you want to add more than just a GUI, so I wonder what this is about?

#3 Updated by segfault 2017-09-29 09:05:49

110100111011 wrote:
> You can mount any veracrypt volume with that. Sure, a GUI for that would be nice, but this feature sounds like you want to add more than just a GUI, so I wonder what this is about?

Yes, it is already possible to use TrueCrypt and VeraCrypt volumes in Tails via cryptsetup, which we also document here. But we want integrate TC and VC support nicely into Tails, i.e. extend the graphical tools which already allow to handle other kinds of encrypted volumes (namely LUKS). This means we plan to extend GNOME Disks (Feature #11684) and GNOME Files (Feature #14464) to allow unlocking of TC and VC volumes. Part of this work is also to upstream these features.

#7 Updated by sajolida 2017-10-03 15:03:03

I’m removing the blocking relationship with Feature #14474. For me Feature #14473 should be done in parallel with Feature #14474 and not be blocked by it:

• The longer we run Feature #14474 the better quantitative results we will have. We won’t have much time already before the sprint, so blocking Feature #14473 would be problematic.
• The idea is to arrive at the sprint with the cost (Feature #14473) and the benefits (Feature #14474) and combine them. Influencing the study of the costs with the benefits might be biased.
• Having ideas of the costs of the bits that we won’t do would be good anyway to sanity check and justify the final scope of the project (and possibly continue it later on).