Does Back In Time need encryption?

Hello, this is an X-Post [1]. The background of this discussion is about marking EncFS as deprecated because of security issues and remove it in some years if no contributor jumps in to replace it with something else (e.g. GoCrypt). It's just a thought that came to mind. It's not a concrete suggestion. But of course, I'm interested in your opinion on it. Isn't it one of the key features of BIT, compared to other backup tools, that you can access the backup itself without using your backup tool? The backup is just a bunch of files and folders you can use and investigate with your regular file system tools. But when you use EncFS (or another way of encryption) this features is lost. I have not used EncFS in the wild. I might be wrong. If EncFS really is the reason for losing this feature I ask myself if it wouldn't be "better" for BIT to really remove EncFS and not replace it with something else. It would give BIT a more focused set of features and behavior. Encryption is another job a user should achieve with another tool; e.g. encrypted file system container or an encrypted filesystem (some LUKS magic). I am aware that there are lot of backup tools out there offering encryption. But these tools producing a backup in a format that can be used (and restored) only with the backup tool itself. So this is a another group of users targeted here. Marking EncFS as deprecated and reading the reactions of users about it will give us an idea about how much needed such a feature is. Best, Christian Buhtz [1] -- <https://github.com/bit-team/backintime/issues/1549#issuecomment-2095373077>

Dear Christian, Since I'm using both macOS and Linux and backup both of them, I think can add my two cents into the discussion. I recently started using full disk encryption on removable drives in macOS and, it brings great peace of mind, hence I understand the need for encryption in backups. As you said, other tools have built-in encryption (e.g. Borg), and you need to mount the backups as filesystems via FUSE. I think, BiT can drop encryption, but it has to replace it with something useful. Like full documentation for creating encrypted volumes on Linux. Because 1) an encrypted FS is portable between Linux installations, 2) We should never leave users without hope. This way, we can both slim the code down and focus on the core functionality of BiT - Provide Time Machine like backups with better features, and delegate an important and sensitive feature to the folks who know it probably better than us. Hope this helps, Cheers, Hakan On 6.05.2024 ÖÖ 10:45, c.buhtz@posteo.jp wrote:

Hi, Chris! Thank you for your thoughts, I strongly agree with your line of thinking. On 06.05.2024 09:45, c.buhtz@posteo.jp wrote:
Yes, definitely. I think it's one of the main points that set backintime apart from other backup tools.
But when you use EncFS (or another way of encryption) this features is lost. I have not used EncFS in the wild. I might be wrong.
Well, yes and no. Let's look at the two fundamental cases: 1) If you create a backintime backup, you can access the backup: 1a) WITH backintime (normal usage), or 1b) WITHOUT backintime (regular file system access, alternative tools, rescue situation). 2) If you create a "backintime+encfs backup", you can access the backup: 2a) WITH backintime+encfs (normal usage), or 2b) WITHOUT backintime but WITH encfs (manually decrypt with encfs, then regular file system access), but: 2c) WITHOUT backintime and WITHOUT encfs, you have no access to your files.
I strongly agree. In the case of EncFS, we also see the "danger" of integrating it tighly with backintime: If EncFS is insecure, a feature of backintime is insecure. If EncFS is abandoned, a feature of backintime is abandoned. The same could (in theory) happen with any other encryption tool that we choose to integrate: GoCryptFS, cryfs or whatever.
And it's easy to do: with LUKS integrated into the kernel, transparent FUSE mounts for filesystem-layer encryption tools etc., you can easily apply any encryption you want to a backintime backup. Just mount your target folder, and backintime go brrrrr ;)
True: duplicati, borg, restic, ... basically, and tool in this list: https://github.com/restic/others that has the tag "encryption", but not "filesystem" (like backintime).
Marking EncFS as deprecated and reading the reactions of users about it will give us an idea about how much needed such a feature is.
My guess is that there will be a small proportion of hardcore users who have grown used to this feature, and who will be disappointed. We might ease their pain by offering a ready-made user-callback script that will mount their encfs target folder (instead of backintime itself doing that). It will not be the same, though, because browsing through the encrypted backups will no longer work without mounting manually (I think). Cheers Michael

On Mon, 2024-05-06 at 07:45 +0000, c.buhtz@posteo.jp wrote:
I think a major use case of automated backups (with BiT and other backup tools) is: --> Just mount the encrypted target device/folder to create the backups and then lock it again. This eg. protects the backups better against trojans that encrypt all your devices to blackmail you. But this use cases requires to automatically mount the encrypted device (= unlock using a secret credential). BiT supports many standard credential managers of Linux via the "keyring" Python package but to unlock the encrypted device BiT needs to know how (= which encryption container) and implement this in Python code And since we do not implement the encryption logic itself our risks of doing something wrong are manageable. So I think 1. unless we drop above uses case we need to support encryption (container) in BiT 2. we should still support EncFS for legacy reasons (users still using it) but give a clear warning about the deprecation (and that it is insecure). Also we should link a FAQ entry how to migrate to another encryption container. 3. For encryption that is transparent to BiT (eg. udev-based mounting of external devices) we should add documentation links (as @Hakan proposed: "[...] Like full documentation for creating encrypted volumes on Linux [...]"

Am 06.05.2024 22:31 schrieb BiT dev:
The way of deprecation marking and removing/replacing is discussed in https://github.com/bit-team/backintime/issues/1549 . I calculate with minimum two official Debian releases, which make it 4 years and more until EncFS is removed/replaced. I think this is kind enough to users who still use EncFS.

Dear Christian, Since I'm using both macOS and Linux and backup both of them, I think can add my two cents into the discussion. I recently started using full disk encryption on removable drives in macOS and, it brings great peace of mind, hence I understand the need for encryption in backups. As you said, other tools have built-in encryption (e.g. Borg), and you need to mount the backups as filesystems via FUSE. I think, BiT can drop encryption, but it has to replace it with something useful. Like full documentation for creating encrypted volumes on Linux. Because 1) an encrypted FS is portable between Linux installations, 2) We should never leave users without hope. This way, we can both slim the code down and focus on the core functionality of BiT - Provide Time Machine like backups with better features, and delegate an important and sensitive feature to the folks who know it probably better than us. Hope this helps, Cheers, Hakan On 6.05.2024 ÖÖ 10:45, c.buhtz@posteo.jp wrote:

Hi, Chris! Thank you for your thoughts, I strongly agree with your line of thinking. On 06.05.2024 09:45, c.buhtz@posteo.jp wrote:
Yes, definitely. I think it's one of the main points that set backintime apart from other backup tools.
But when you use EncFS (or another way of encryption) this features is lost. I have not used EncFS in the wild. I might be wrong.
Well, yes and no. Let's look at the two fundamental cases: 1) If you create a backintime backup, you can access the backup: 1a) WITH backintime (normal usage), or 1b) WITHOUT backintime (regular file system access, alternative tools, rescue situation). 2) If you create a "backintime+encfs backup", you can access the backup: 2a) WITH backintime+encfs (normal usage), or 2b) WITHOUT backintime but WITH encfs (manually decrypt with encfs, then regular file system access), but: 2c) WITHOUT backintime and WITHOUT encfs, you have no access to your files.
I strongly agree. In the case of EncFS, we also see the "danger" of integrating it tighly with backintime: If EncFS is insecure, a feature of backintime is insecure. If EncFS is abandoned, a feature of backintime is abandoned. The same could (in theory) happen with any other encryption tool that we choose to integrate: GoCryptFS, cryfs or whatever.
And it's easy to do: with LUKS integrated into the kernel, transparent FUSE mounts for filesystem-layer encryption tools etc., you can easily apply any encryption you want to a backintime backup. Just mount your target folder, and backintime go brrrrr ;)
True: duplicati, borg, restic, ... basically, and tool in this list: https://github.com/restic/others that has the tag "encryption", but not "filesystem" (like backintime).
Marking EncFS as deprecated and reading the reactions of users about it will give us an idea about how much needed such a feature is.
My guess is that there will be a small proportion of hardcore users who have grown used to this feature, and who will be disappointed. We might ease their pain by offering a ready-made user-callback script that will mount their encfs target folder (instead of backintime itself doing that). It will not be the same, though, because browsing through the encrypted backups will no longer work without mounting manually (I think). Cheers Michael

On Mon, 2024-05-06 at 07:45 +0000, c.buhtz@posteo.jp wrote:
I think a major use case of automated backups (with BiT and other backup tools) is: --> Just mount the encrypted target device/folder to create the backups and then lock it again. This eg. protects the backups better against trojans that encrypt all your devices to blackmail you. But this use cases requires to automatically mount the encrypted device (= unlock using a secret credential). BiT supports many standard credential managers of Linux via the "keyring" Python package but to unlock the encrypted device BiT needs to know how (= which encryption container) and implement this in Python code And since we do not implement the encryption logic itself our risks of doing something wrong are manageable. So I think 1. unless we drop above uses case we need to support encryption (container) in BiT 2. we should still support EncFS for legacy reasons (users still using it) but give a clear warning about the deprecation (and that it is insecure). Also we should link a FAQ entry how to migrate to another encryption container. 3. For encryption that is transparent to BiT (eg. udev-based mounting of external devices) we should add documentation links (as @Hakan proposed: "[...] Like full documentation for creating encrypted volumes on Linux [...]"

Am 06.05.2024 22:31 schrieb BiT dev:
The way of deprecation marking and removing/replacing is discussed in https://github.com/bit-team/backintime/issues/1549 . I calculate with minimum two official Debian releases, which make it 4 years and more until EncFS is removed/replaced. I think this is kind enough to users who still use EncFS.
participants (4)
-
BiT dev
-
c.buhtz@posteo.jp
-
Hakan Bayındır
-
Michael Büker