Transition of encryption feature: Remove EncFS (and replace it if possible) until year 2029/30

[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.

1. One is to improve the handling of encrypted file systems and encrypted storage devices.
2. The other is to replace EncFS with a similar alternative, e.g. GoCrypt.

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

• June 2024: LUKS is not a replacement for all use cases (see Issue comment). So we should force to replace EncFS with GoCrypt or something else.
• May 2024: In the beginning.

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

• feat+docu(EncFS): Deprecation warning in the GUI and details in whitepaper #1735
• feat+docu(EncFS): Research about how to handle encrypted drives and how BIT can help with that #1736
• EncFS: Intense GUI warning about its removal #1904
• Implement alternative solution (e.g. handling encrypted volumes and improved docu). (PR Add local gocryptfs support #1897)
• Disable creation of EncFS snapshot profiles in the GUI. But let existing ones work.
• Disable EncFS code and offer docu about how to access existing EncFS snapshots without BIT.
• Remove EncFS code.

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.

1. Year 2024: Clear and strong warning about the planed removing or replacement of EncFS.
2. After Debian 13 released (year 2025 or 2026): Disable creation of new EncFS profiles. This become "relevant" for "Debian stable" users round about year 2027/28 when Debian 14 is released.
3. After Debian 14 released (Year 2027 or 2028): Remove EncFS in upstream BIT.
4. Debian 15 in year 2029 or 2030: Our transformation then has reached Debian stable.

Additional details

• First discussion about deprecating EncFS was in Mark EncFS as deprecated feature and inform the users about it #1549.
• The security issues of EncFS at discussion:
  • EncFS Security Audit
    • https://defuse.ca/audits/encfs.htm (as updated blog post)
    • https://sourceforge.net/p/encfs/mailman/message/31849549/ (original mailing list entry)
  • EncFS development ? vgough/encfs#314 (a not-fixed meta issue with a list of several open issues related to the Security Audit)
  • Current security status vgough/encfs#659
  • Stream Cipher Used to Encrypt Last File Block vgough/encfs#9
  • https://wiki.ubuntuusers.de/Archiv/EncFS/ (German archived Ubuntu Wiki)

[bentolor]

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 Benjamin,
thanks a lot for your feedback. Comments like this are one reason why that issue exist.

My take home message is that a file system encryption (like LUKS) won't solve everyone's problem and is not a 100% replacement for EncFS.

One goal of this issue also is to attract contributors. Having someone replacing EncFS would be great. But currently we do not have one. To my knowledge GoCrypt should be a nearly perfect replacement for EncFS. The EncFS maintainer himself do recommend GoCrypt as a replacement.

Kind
Christian

[daviewales]

GoCryptFS does look like a near drop-in replacement for EncFS.
However, it won't be able to read existing EncFS backups.

If GoCryptFS support is added, would you want to include an automatic migration feature from EncFS?
Or would you just remove EncFS and add GoCryptFS, and people would need to manually migrate backups?

I imagine that just swapping them out is quite achievable.
Adding an automatic migration would be a bit harder.

[emtiu]

I don't think an automatic migration functionality is feasible. The potential for failure would be very high, so it's better to leave this up to the users, who will be forced to set up new backups, or copy the existing snapshots manually.

It's painful, but it's much more realistic.

[bentolor]

Technically even a migration would equal a complete rewrite of a full backup set. As encryption occurs on client side, I'd not see any win in terms of speed, data transfer volume etc.

In comparison just asking users to create a fresh, GoCryptFS backup set (and deprecate, but keep the EncFS approach for a transition phase) appears to be most reasonable and straightforward to me.

[buhtz]

In comparison just asking users to create a fresh, GoCryptFS backup set (and deprecate, but keep the EncFS approach for a transition phase) appears to be most reasonable and straightforward to me.

Yep, that is the plan. And even after EncFS is removed from BIT users are able to use an older BIT version to rescue their backup or using EncFS themself to "open" the encfs folders without using BIT.

[daviewales]

Thanks. I was looking at the code, and simply swapping GoCryptFS in place of EncFS looks quite doable. Do I understand correctly that your plan is slightly more complicated: to support both EncFS and GoCryptFS for a transition period?

…

On 9 August 2024 12:19:50 am AEST, buhtz ***@***.***> wrote: > In comparison just asking users to create a fresh, GoCryptFS backup set (and deprecate, but keep the EncFS approach for a transition phase) appears to be most reasonable and straightforward to me. Yep, that is the plan. And even after EncFS is removed from BIT users are able to use an older BIT version to rescue their backup or using EncFS themself to "open" the encfs folders without using BIT. -- Reply to this email directly or view it on GitHub: #1734 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[buhtz]

Yes.

[emtiu]

Thanks. I was looking at the code, and simply swapping GoCryptFS in place of EncFS looks quite doable. Do I understand correctly that your plan is slightly more complicated: to support both EncFS and GoCryptFS for a transition period?

I think it's a very good idea to just try this out, even if the final implementation might look a little different. If you feel up to the task, why not take a fork/branch, and implement a 1-to-1 replacement of encfs with GoCryptFS? Just to see how it goes – it will probably teach you/us some useful things to know for the future :)

[daviewales]

Thanks, I'll give it a shot if I get some time.

[buhtz]

I fully support all this and glad you try to jump in here.
Just one wish. Please try to keep the PRs as small as possible. I am not familiar with the involved code but I am assuming this won't always be possible.