[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251014175218.GB566507@mit.edu>
Date: Tue, 14 Oct 2025 13:52:18 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: John Stultz <jstultz@...gle.com>
Cc: Arnd Bergmann <arnd@...db.de>, Matthew Wilcox <willy@...radead.org>,
Arnd Bergmann <arnd@...nel.org>, Tyler Hicks <code@...icks.com>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
ecryptfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ecryptfs is unmaintained and untested
On Tue, Oct 14, 2025 at 09:38:52AM -0700, John Stultz wrote:
> Yeah, though to my understanding fscrypt complicates backing up the
> data in its encrypted form.
Unfortunately, yes, that's correct. Michael and I did throw around a
rough design for doing encrypted backups and saving the encrypted
per-file encryption key. Actually doing the _backup_ wasn't that
difficult; but doing the *restore* was very tricky/painful.
Ultimately, we never implemented it because it wasn't necessarily for
the Android/ChromeOS use case, and because we weren't getting a lot of
interest for the desktop, without which having a better
general-purpose backup is lower priority.
> I've wondered if maybe something as simple as fuse mounting a password
> protected zip file would do, but I'm guessing something a little more
> modern like a fuse + age approach would be better. Unfortunately I'm
> not finding anything so far.
Darrick is doing a lot of work to significantly improve the
performance of fuse2fs. So perhaps fuse mounting a dm-crypt device
backed by a loop device might be a possibility?
- Ted
Powered by blists - more mailing lists