Skip to content

Navigation Menu

Sign in
Sign up

Feature poll for the Tomb v3 roadmap #457

Unanswered
jaromil asked this question in Q&A
Discussion options

TL;DR: https://github.com/dyne/tomb3

Old poll: https://doodle.com/poll/2is26dx72x2s27cn

Hi everyone, I've been planning to work on Tomb v3 for a while now.

The objectives I have, in order of importance, are:

  1. portable usage on windows and mac
  2. keep consistent with the user experience in v2
  3. increase the security of keys
  4. backward compatibility with tombs built with v2

In order to realise them I would like to have a larger reality check with you all about the features in v2 that are most precious for your workflow and that are generally most useful.

Here is a POLL for the Tomb v3 feature plan and I'll be grateful to all those who like to chip in their ideas and experience. Please excuse the ads of the site, hope you don't mind, its just a quick way to get some feedback.

At last don't you worry about this initiative because Tomb v2 is made to stay: it will keep being available here and will keep doing what it already does at its best. The development happens on a new Tomb3 repository.

ciao!

You must be logged in to vote

Replies: 11 comments

Comment options

jaromil
Jul 21, 2021
Maintainer Author

Quick update on this poll, as of today we have in order of priority

  1. list (11)
  2. resize (10+1)
  3. slam (9+2)
  4. bind mount hooks (6+4)
  5. bury / exhume key in jpg (6+2)
  6. asymmetric crypto to multiple recipients (5+2)
  7. index / search (..6)
  8. cloak / uncloak key in txt (..6)
  9. ps processes using (3+2)
  10. exec hooks (2+3)
  11. engrave key to QR code (1+2)
  12. sphinx key store on remote server (1)

A new feature request is the ability to handle partition-based device encryption made with LUKS, perhaps adding a tomb key in a slot of an existing encrypted volume, see issue #422

If there is any other feature we should take into account please add your comment.

You must be logged in to vote
0 replies
Comment options

I would have thought mounting without sudo (#322, #197). Don't see that on the list. That and #254 would all be worthy security improvements.

You must be logged in to vote
0 replies
Comment options

Adding my support for portable usage on Windows and other BSD based systems like MacOS 😄 . Am wondering what the approach will be here, considering cryptsetup is not available cross-platform to the best of my knowledge?

You must be logged in to vote
0 replies
Comment options

jaromil
Jul 21, 2022
Maintainer Author

Portability status:

  • Windows: since v11 the Linux subsystem supports loopback mounts and AES encryption (only, no serpent) in dm-crypt, hence Tomb works (tested!)
  • OpenBSD does not support loopback mount, no solution in sight
  • FreeBSD and NetBSD not investigated yet (hints?)
  • AppleOSX investigated long ago, docker is insufficient, not sure if any reliable port of cryptsetup is available today
  • Android needs root to operate Tomb from Termux. Vanilla devices may be able to operate userland cryptsetup through Guardian project efforts? last time I looked it wasn't ripe
You must be logged in to vote
0 replies
Comment options

@jaromil Your comment, for the most part, summarizes my current understanding of LUKS on platforms other than Linux: some BSDs do support LUKS, Dragonfly BSD being one that comes to mind.

I wonder whether the way forward (ie Tomb3) is to use other disk encryption specifications and/or file systems that are cross-platform.

OpenZFS comes to mind, w/ cross-platform support for all major operating systems. We also avoid having to use FUSE based solutions, and simply load the appropriate kernel module for one's OS. In doing so, we can keep Tomb as a lightweight wrapper around several commands. I recall reading the following HN article before finding Tomb: https://news.ycombinator.com/item?id=30297188

This however, would kill all possibility for backwards compatibility w/ Tomb2.

You must be logged in to vote
0 replies
Comment options

jaromil
Jul 21, 2022
Maintainer Author

@jensrischbieth Tomb 3 will break backwards compatibility with Tomb 2. I will keep maintaining both solutions.

You must be logged in to vote
0 replies
Comment options

@jaromil I see. Was going off of your objective list at the start of this thread.

In such a case, I see nothing preventing the adopting of another filesystem and/or disk encryption standard that works cross-platform. In the case that OpenZFS ends up being the chosen standard, creating an encrypted zpool isn't too difficult. Tomb3 could also inherit many useful ZFS options, such as compression and passphrase-only encryption, exposing these to the user.

Feel free to push back if you know of a better solution to the problem. ZFS is not without its drawbacks 😄 .

You must be logged in to vote
0 replies
Comment options

jaromil
Jul 21, 2022
Maintainer Author

@jensrischbieth thanks, I know fairly well and love ZFS, my private RAID-Z fileserver is >10yrs old and has never failed me, but I never used its encryption functionality. I'll consider it and do some tests, meanwhile I'm not really in a rush for Tomb v3

You must be logged in to vote
0 replies
Comment options

jaromil
Oct 19, 2022
Maintainer Author

Dears, I have started Tomb v3 development

It starts with an explanation of goals and features I've gathered from our interaction, the focus and list of features is not final, but won't make a lot of changes as this is something I really need myself. In particular and about OpenZFS I am testing that v3 tombs (ext4 formatted) work well on FreeBSD and can be easily stored inside ZFS volumes.

You must be logged in to vote
0 replies
Comment options

jaromil
Nov 14, 2022
Maintainer Author

I have changed my mind about how these enhancements will be introduced and the shape of the v3 roadmap.

There won't be a separate v3 repository, but two new "flavours" of tomb will be redistributed along with it:

  • portable based on veracrypt and POSIX sh
  • ZFS based on ZFS volume encryption

A proof of concept of portable tomb is already available in the repository and will be redistributed as a developer preview in the new upcoming 3.0 release series.

You must be logged in to vote
0 replies
Comment options

As far as I understand this effort has been abandoned altogether?

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
discussion help wanted An issue open for contributors to help
Converted from issue

This discussion was converted from issue #409 on November 27, 2022 07:15.

AltStyle によって変換されたページ (->オリジナル) /