bentolor
commented
3 weeks ago Thanks for the heads up and extensive wrap-up of the current situation, @buhtz. I also want to express my deepest gratitude towards the original maintainer @Germar as well as the new maintainer in their efforts to provide the Linux community an accessible and secure backup tool over these years. BIT has provided users like me an invaluable benefit in protecting my personal data stash over the past years (or even decade?).
I just want to add a user voice and feedback, that some of the envisioned alternatives (i.e., LUKS) are not an suitable option for an adequate replacement, at least for my user persona.
Prior to choosing BIT as backup solution, I did an extensive research on available backup solutions, and at that time BIT appeared to be the only solution fitting my bill. Before jumping into the details, a few initial thoughts:
IMHO, A solid and good (consumer) backup should be
- spatially separated (read: located in a remote location on independent system)
- temporarily separated (read: "snapshots")
- incremental and efficient (read: send and store changes as minimal as possible)
- allow to ensure the exclusive sovereignty over my data (read: Nobody at the backup target should be even technically able to see my plaintext data).
The case for BIT and EncFS
In my setup (Homeserver: ZFS ZRAID on LUKS, 3+ TB volume, Backup-Target: Remote NAS via 10Mbit WWAN, SSH, rsync & encfs) BIT and EncFS wonderfully checks that bill and comes with a few extra benefits:
- the magic of rsync offering deduplication and deltra transmission over the line
- the easy accessible folder structure for snapshots due to the magic of rsync & hard links
- the straight-forward (though vulnerable) security approach of EncFS encryption on client side.
My key point
So the key properties of my user persona point are:
- Having a huge backup dataset
- A remote location with relatively "slow" connection link
- And an untrusted backup target
I do not know about GoCrypt. But I'm pretty sure, that a LUKS-based approach would no longer fit my bill. Simply said: To ensure my data sovereignty, the encryption must happen at backup source site. This would require to remotely mount the block device loosing all the target-sided benefits of rsync. This approach might be feasible with a high-speed, low-latency connected, trustworthy backup device in a local network. But In an "spatially separated" setting without T1 connection, the latency and bandwith would render large volume backups nearly impossible. A target-side LUKS-approach on the other hand would compromise the user sovereignty, as he now needs to trust the target.
My PoV
In case GoCrypt is not a viable conceptually drop-in replace for the current EncFS architecture, I'd rather recommend users with an untrusted backup target like me to switch to a archive-based backup solution offering encryption as first-class citizen like https://www.borgbackup.org/ (Vorta), https://restic.net/, https://duplicati.com/ or maybe https://duplicity.us/ (DejaDup). I think this is the better and more appropriate approach in contrast to an target-side encryption approach like LUKS as alternative.
Nevertheless, I still appreciate that the BIT-team takes the initiative and lead in this matter, even if this means as an outcome to eventually switch my backup approach, as the current EncFS situation has been already not on par for a long time. Sticking to the status quo is not a good approach when it comes to security.
Again: I appreciate your efforts and thank you for keeping us posted!
buhtz
Hello User & Contributors
Your Back In Time (BIT) likely gave you a hint that the encryption function will soon change. As maintainers, we're keen on your opinion and perspective on this matter. Please direct questions and ideas preferably to the project's mailing list or one of the subordinated issues (see below), as this issue serves more for organization than substantive discussion.
Summary
The transition is about removing EncFS and provide one of two alternatives.
~In the current state of discussion it is preferred not to replace EncFS with an alternative library but to use encryption on file system level (e.g. LUKS) and improve BIT in a way to easier handle file systems like this.~ The current state of discussion is that using LUKS or another file system encryption managed by the operating system itself (outside of BIT) is not a solution for all BIT users but for some (see Issue comment). So we better should replace EncFS if we do find contributors. If we don't we need to accept cutting of a feature and some users with removing EncFS without replacement.
The transition is a process not fixed in all details and planed to take until the year 2029 or 2030. It was born from the idea to remove EncFS or replace it because EncFS has known security issues and the upstream project is not active anymore. It is also the case that there is currently no Back In Time contributor replacing EncFS. To keep BIT secure and maintenable there is no alternative to deprecat EncFS in BIT and finally remove it.
Current state
The final goal
It is not finally decided how the situation will be at the end in some years. The state of the current discussion is to remove encryption from Back Im Time because it can be handled by the file system itself. However, the removal should be accompanied by improved documentation on how to use Back In Time with an encrypted filesystem. Additionally, it will be considered whether BIT should be enhanced with functionality that makes it easier for users to handle and mount encrypted filesystems (e.g., on external storage).
Issues to taken care of
1735
1736
Roadmap until year 2029 or 2030
Slow and transparent steps in a timeline of multiple years until round about the year 2029 or 2030 when Debian 15 will be released. Current stable Debian is version 12. It is build around the release cycles of Debian GNU Linux because Debian has very long release cycles and is the base for most of the distributions out there.
Additional details