public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: John Stultz <jstultz@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Matthew Wilcox <willy@infradead.org>,
	Arnd Bergmann <arnd@kernel.org>, Tyler Hicks <code@tyhicks.com>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: ecryptfs is unmaintained and untested
Date: Tue, 14 Oct 2025 10:39:16 -0400	[thread overview]
Message-ID: <20251014143916.GA569133@mit.edu> (raw)
In-Reply-To: <CANDhNCpsoPcotnrjH6y0yEBf43652DRasSsEnAyEbrKN=tjEfQ@mail.gmail.com>

On Mon, Oct 13, 2025 at 11:07:56PM -0700, John Stultz wrote:
> 
> Yeah. Sadly I'm one, as I needed something to migrate off of when
> encfs was deprecated.
> 
> Is there another soon-to-be-deprecated filesystem to encrypt
> directories I should move to? :)

Well, the closest way of encrypting directories is fscrypt.  The good
news is that it works on top of btrfs, ext4, f2fs, and ubifs, and it's
not likely to be deprecated given that it is used by chromeos and
android.  The bad news is that the integration with traditional Linux
desktop setups (e.g., login, etc.) was never completed.

This is probably because for many desktop and server configurations,
using dm-crypt is actually better suited and more secure.  It
certainly doesn't solve the "just encrypt a directory hierarchy in a
file system" and the "support multiple users' who might have different
encryption keys and which are mutually suspicious" use cases.  But
this appears to not be sufficiently interesting for distributions to
do that integration work.

					- Ted

  reply	other threads:[~2025-10-14 14:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-28 14:18 [PATCH] eccryptfs: select CONFIG_BUFFER_HEAD Arnd Bergmann
2024-10-28 15:02 ` ecryptfs is unmaintained and untested Matthew Wilcox
2024-10-28 21:50   ` Arnd Bergmann
2024-10-29  4:33     ` Theodore Ts'o
2024-10-30 21:06       ` Tyler Hicks
2026-02-16 11:53         ` René Herman
2025-10-14  6:07       ` John Stultz
2025-10-14 14:39         ` Theodore Ts'o [this message]
2025-10-14 16:38           ` John Stultz
2025-10-14 16:54             ` Martin Steigerwald
2025-10-14 17:52             ` Theodore Ts'o
2025-10-14 16:52           ` Martin Steigerwald
2025-10-14 20:35           ` Eric Biggers
2025-10-15  1:31             ` Theodore Ts'o
2025-10-15  2:23               ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251014143916.GA569133@mit.edu \
    --to=tytso@mit.edu \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=code@tyhicks.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox