intrigeri: > sajolida wrote (01 Apr 2015 11:08:49 GMT) : >> intrigeri: >>> sajolida wrote (20 Mar 2015 12:34:35 GMT) : >>>> I think that our long-term objective is to have people move out of >>>> using TrueCrypt technologies in general (be it the software, the >>>> volumes, or the containers). >>> >>> Now you make me curious: why do you think we should get rid of the >>> TrueCrypt on-disk format? > >> I was saying this because I thought it was our vision when getting rid >> of TrueCrypt, > > This doesn't match my memories, quite the contrary. There must have > been a fair amount of misunderstanding along the way. See e.g.: > https://mailman.boum.org/pipermail/tails-dev/2014-April/005596.html > > Now, I can very well imagine having contradicted myself somewhere > else, or another thread having lead us collectively to the vision > you're referring to, that I really can't remember.
Fair enough, thanks for updating my memory. >>> The way I see it, we're stuck between a rock and a hard place: >>> >>> Ideally we'd like to be able to fully replace TrueCrypt volumes (I'm >>> assuming that I'm missing information that makes you think we should) >>> with something else, but nothing equivalent exists yet. Sadly, I'm not >>> aware of any plan (let alone serious effort) towards making this >>> a reality, when one takes into account the need for: >>> >>> - inter-operability (which I'm tempted to disregard as a dangerous >>> way to share data with an untrusted OS, but then if we don't >>> support TrueCrypt volumes at all, perhaps users who won't/can't >>> fully give up proprietary software will just be forced to either >>> store and share the very same data in cleartext, or to use >>> something less safe than Tails) >>> >>> - "hidden" volumes (which may be a false promise in TrueCrypt, but >>> still people want that and AFAIK there's nothing even approaching >>> it, be it in terms of peer-review of existing production-quality >>> implementations) > >> Thanks to Jasper we can add "containers" to that list. > >> All those are usability and interoperability issues that have real but >> non-obvious security implications (not in terms of crypto but in terms >> of user scenario). I'm not really convinced by containers and hidden >> volumes as such in the context of a pure Tails setup, so we're left with >> interoperability as the most interesting feature. > > Agreed. > >>> With this in mind, supporting the TrueCrypt on-disk format (even >>> minimally) still makes sense for the time being IMO. I doubt we'll >>> actively patch out the corresponding code from cryptsetup, so I take >>> for granted that we'll keep this support in Tails as long as >>> cryptsetup has it. > >> Agreed. > > :) > >>> We had good reasons to get rid of the TrueCrypt software itself, but >>> no existing GUI for TrueCrypt volumes is satisfying right now, in the >>> context of Tails. >>> >>> Now, of course a CLI-only interface isn't encouraging for Tails users >>> to go on using TrueCrypt volumes. This has both advantages (as >>> a long-term strategy, hopefully it'll encourage people to either fully >>> replace TrueCrypt volumes with a better design), and drawbacks (until >>> our fancy long-term plans are made real by $someone $some_day, Tails >>> users have the choice between using something we claim we don't really >>> support, with poor usability, and doing something even worse). >>> >>> So, the question I'm coming to is: assuming there *was* satisfying GUI >>> support for the TrueCrypt on-disk format (in GNOME Disks, Nautilus, >>> etc.), would we want to explicitly support that, or still depict it as >>> a suboptimal feature, and call it unsupported because we think it >>> should ideally be replaced by something else on the long term? > >> We have a long tradition of advertising only one tool for one job. So >> what would we advertise TrueCrypt for? Exchanging encrypted data with >> other operating systems? With big fat warnings? Maybe... > > I don't think that the "only one tool for one job" argument is very > relevant here. First, because the scenario you're replying to is about > adding support for the TrueCrypt on-disk format to existing tools > (GNOME Disks and friends). Secondly, because GNOME Disks and friends > support more than one filesystem, more than one partition table > format, etc., so supporting another on-disk encryption format is no > big deal as I see it. Third, because the same reason that led us to > document keyringer (basically: it doesn't solve _exactly_ the same use > case as KeePassX) applies just fine here too. I agree with you. I overplayed the "only one tool for one job" argument. I was mostly not seeing ourselves advertising TrueCrypt as an alternative to LUKS for general disk encryption ("you can use LUKS or use TrueCrypt"). > Now, regarding the "advertising" part: yes, I think it should be > documented (if at all) only for interoperability purposes. > I'm writting "if at all" because people who want to use TrueCrypt > volumes can create them on their other OS, and then all we need on our > side is documenting how to unlock/open such volumes in Tails. The good > news is that we already have a perfect place for that, which is > doc/encryption_and_privacy/truecrypt :) Right, so if we ever get graphical tools to do that we'll replace the command line instructions with graphical instructions. >>> In other words: how hard should we push for adding support for the >>> TrueCrypt on-disk format in udisks and friends? (Until 15 minutes ago, >>> I was convinced that it was the way to go, and prepared to go ping the >>> right folks about it, but now you've planted some non-negligible >>> amount of doubt in my mind, so I'm a bit lost in terms of strategy.) > >> Me too :) > > I'm not lost anymore since you clarified that you're not aware of good > reasons why we should get rid of the TrueCrypt on-disk format. > The path forward seems pretty clear to me again. Then I'll let you create tickets or send emails upstream accordingly, because the underlying technicalities are not clear enough to me. -- sajolida _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.