Mark EncFS as deprecated feature and inform the users about it #1549
Comments
buhtz
added
Feature
|
Any message that BackInTime should display to users should clearly state that "EncFS support will be removed from BackInTime in the future". The reason that we need to be so clear is that EncFS users have been seeing "EncFS is not really secure, do you really want to use it?" messages for a while. They are likely to disregard 'just another warning about EncFS security'. |
|
Please do NOT REMOVE EncFS support completely. People would loose access to their backup, they relay on! You can add some strict warning messages if someone adds a new EncFS profile and also a hint for current EncFS profiles. But removing the whole feature would be to harsh. |
|
I do understand your concerns. People won't lose access to their backups because they are warned early enough. Depending on the distribution channel they do use they have a time periode of 2 to 5 years after the first appearance of the warning message. And this period is not even fixed and can be expanded of course depending on the feedback of our users. They also don't lose access because in my udnerstanding they don't need BIT to access the snapshot folders but just EncFS itrself. We can not keep unmaintained and unsecure code. It is fact that the code need to be replaced. Currently no one of the active maintainers will do the replacement, not even in the future because our priorties are different and we do not use that feature ourself. One intention of the alarming deprecation message is to attract new contributors. If the need is there someone will step up. Maybe the EncFS project itself will be reactived. We don't know. Let's see what happens in 5 years. But we need to warn the users as soon as possible that something will come up. EDIT: To become a bit off topic, because the issue is about the warning message and not a future solution, we can make EncFS a read-only feature until the time period elapsed. And then no creation of new EncFS profiles and no "take snapshot" of existing EncFS profiles. Then we can add another time period until we remove (or replace) the EncFS related code. |
buhtz
added
the
Feedback
|
The next release is round about in two weeks. I assume this is to short to implement a solution for this Issue. I see no alternative to mark EncFS as deprecated because we do not have anyone to fix it or replace it by an alternative. |
|
Note: EncFS upstream seems to be dormant (4 years). Opened an Issue about project status and also asked Debian maintainer "blade" about future plans for the EncFS package. |
|
So, here is "blade". And after reading the rather confusing mail I keep wondering why you suddenly want my package to be removed from Debian. Sorry, what is all this fuzz about?! |
|
Dear blade, The security issues at discussion:
I was just asking if you, as debian maintainer, have any plans to remove that package and when could this be. |
|
Dear blade/Code7R, Kind |
|
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. |
|
I agree, it would benefit backintime (less complexity, more focus on key features) to delegate encryption (as well as compression) to other layers, managed by the user. We could offer supporting user-callback scripts to sort-of replace the current functionality. Generally speaking, it's backintime's strength to just write backups to a filesystem (mounted or remote), as long as it supports hardlinks. Any other filesystem-level operations can more elegantly be handled separately. |
|
There have been no new arguments or further objections against the undertaking in general. Beside the discussion in this issue thread, there are some important aspects discussed on the mailing list in Does Back In Time need encryption?. Since this blocks the upcoming release, I make the following proposal and will start to implement it step by step. It is a long process taking multiple years. It is intended to start a discourse with our users. It might be that the process will go into a totally different direction then proposed today. 🚗 We are flexible. 😄 Because this topic is quit complex I tend to create a new meta issue summarizing the tasks and steps need to be done and also having separate issues for each of that steps. The final goalIt 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). The first stepThe situation need to be communicated to our users clear and early as possible. That is why I need to get this solved before the next release. Beside messages in BIT GUI itself there need to be separate documents (here in the repo) describing our plans and intentions. This is done with the assumption that it will spark a discussion with users and generate new ideas and impulses. Hopefully, this will help us reach a final decision on whether encryption should really be removed or if we should pursue an alternative like GoCrypt and seek a contributor for that. Overall timeline until year 2029 or 2030I do propose the following 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.
|
|
OK, I am closing this redirecting to the follow up transition issue #1734 . |
As discussed in #1248 EncFS need to be replaced because of security reasons but currently there are no ressources to do this.
Because of this we need to remove EncFS someday no matter if there is a replacement or not.
As a first step that feature should somehow marked as deprecated and the users should be informed about it.
Additionally we need to find a roadmap for this and also inform the user about that.
My suggestion:
This is a lot of time. Debian (stable) users can stick to that feature for the next 4 years until the next after the next stable release (round about 2027/28) comes out. Users of rolling release distros or similar will have this feature for 2 years.
Maybe the deprecated message will draw some potential contributors. So we might have a replacement before EncFS is removed.
EDIT:
The discussion on bit-dev mailinglist about the necessity of an encryption feature in BIT at all brought up an idea from Michael. He suggested to "offering a ready-made user-callback script that will mount their encfs target folder".
The text was updated successfully, but these errors were encountered: