Will EncFs be replaced?

[1fexd]

Hi,

will EncFs ever be replaced with a more secure alternative in the future, or should I switch to another solution for encrypted remote backups?

[mossroy]

There had been some discussion on replacing encfs by gocryptfs: #644, and some initial work in branch gocrypt: https://github.com/bit-team/backintime/tree/gocrypt

But it seems stalled (no change in the last 4 years).

Encfs probably has flaws, but is still better than nothing. If it's not enough for you, consider switching to another solution

[buhtz]

Would one of you please describe a use-case for EncFS/GoCryptFS?

I am not aware of it and don'T understand where it belongs in the context of BackInTime.

When it comes to encrypted file system I would assume that this is the responsibility of the operating system and not BIT. But it seems I'm wrong here. So please teach me. ;)

[mossroy]

It's usually interesting when you put your backup in a remote location that you cannot fully trust.
An administrator of the remote server could read your backup for example (even with an encrypted filesystem)
By locally encrypting your data before sending it, you can safely put it in this remote location.

In our case, EncFS is known to probably have flaws, so the "safely" is not really true (even if it's still better than putting the data in cleartext)

[buhtz]

OK I understand.

But how does this integrate in BIT?

From my understanding you "mount" (e.g. to /mnt/mysecrets) the encrypted FS on a operating system level and then start BIT using that mount point as a destination.

I don't see why BIT use EncFs "inside" and depends on that.

Taking a snapshot involves a lot of steps for BIT. On which of that steps is EncFs involved?

Maybe I am wrong: But in my experience BIT doesn't mount something for you. You have to use the user-callbacks to handle that.

[mossroy]

When you configure an encryption password in BiT, it does all the necessary for you: it mounts a temporary location using encFS, that relies on a local or sshfs location.

[buhtz]

This here?
https://backintime.readthedocs.io/en/latest/settings.html#local-encrypted

Please let me ask:
Does BiT really need that feature? There are a lot of solutions out there creating encrypted FS. Why not let them (and the operating system) take care of that?

I don't mean this feature is useless, stupid or luxury!
I just ask from the maintainer perspective taking available resources into account. And I wan't to understand the priorities of the users.

[mossroy]

No, the use-case I was mentioning is more https://backintime.readthedocs.io/en/latest/settings.html#ssh-encrypted

If BiT does not encrypt the data before sending it to a remote server, it implies a lot of trust on this remote server: you have to trust the admins, the hoster, and you are "naked" if this server is compromised.

If BiT encrypts/decrypts the data on-the-fly (like it currently does with encFS), you have a much higher security: even if this server is compromised, the data on it is still unreadable (without the password). It allows you to put your backups in a lot more kinds of servers, and is an additional security in all cases.
(this would however be even more true if BiT used a better encryption library)

[buhtz]

The transfer itself is encrypted everytime because it use SSH.

But you mean the storage volume on the server, right?
Of course it would be a bit uncomfortable but you mount the volume on the server and then "open" the encrypted filesystem (container?) on it. Both steps can be done without BIT.

Maybe I get it better when I see it in a video.

The question is if EncFS (or something else) is mandatory to store snapshots on an encrypted filesystem?

[mossroy]

The transfer itself is encrypted everytime because it use SSH.

Yes

But you mean the storage volume on the server, right?

Yes

Of course it would be a bit uncomfortable but you mount the volume on the server and then "open" the encrypted filesystem (container?) on it. Both steps can be done without BIT.

Probably. But if you schedule the backups, it means either that you have a permanent mount on the encrypted filesystem (automatically reconnected after a deconnection?), or that you have some kind of script that mounts/unmounts it when needed (to reproduce what BiT currently does by itself)
It would be possible, but very user-unfriendly.

To me, client-side encryption is a must for a backup software when you use external backups (it's my case). Most end-user backup tools do that.
Dropping this feature in BiT would mean it focuses on local backups only (by "local", I include servers on the local network, but not outside).

Maybe I get it better when I see it in a video.

Which video? I don't get you

The question is if EncFS (or something else) is mandatory to store snapshots on an encrypted filesystem?

I did not get into the code or tested it. When backing up through ssh, it might be doable by hand, but is not a one-shot operation like formatting a hard drive with LUKS/dm-crypt (that could be seen as an easy alternative when backing up locally). You need to setup on-the-fly encryption/decryption over ssh by yourself: I doubt people will do that.

[buhtz]

OK, I understand the feature now and how it works. I also understand it could be done by an external script (e.g. user-callback).

But I agree it is a usual and important feature for backup software.

In short: You convinced me to give my vote to keep that feature. :)

[emtiu]

I agree that the "automagic" encfs integration is a good and useful feature. But development on such encrypted filesystems seems to be very slow, generally. So the most relevant question is: Which software even exists for this exact job?

As far as I'm aware, it's:

• encfs (very mature, but known to be vulnerable, no release since 2018)
• gocryptfs (most mature alternative?)
• CryFS (still in beta?)

For further hints, see: https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems, but most of the software mentioned there seems to be unfit for our purposes.

[buhtz]

After one year working with BIT and becoming warm with its problems and the work that has to be done I don't see that some of the current maintainers will add a replacement for EncFS.

We should think about in the long run to remove EncFS without replacement. I see no other way if no one else stands up and help with it.

We should decide this soon (until end of this year) so we can inform our users in the next two (or more) releases that this feature is deprecated and will we be removed. Maybe this deprecation message can attract new contributors. But I assume EncFS-BIT-users will migrate to other tools. There is e.g. borg-backup or restic that do support encrypted backup containers.

When thinking about Debian release cycles. The latest release with EncFS including a deprecation message should be in 2025 when Debian 13 is stable and released. This is much longer then I would like to have it but we need to take Debian into account as being the base of round about half of all existing GNU Linux distros.

One important question here is how insecure is EncFS? I don't work with it and don't have expertise in it. Can someone give an advise or link to relevant ressources?

Further reading

• Discussion about EncFS alternatives on AskUbuntu

[Germar]

I started to implement gocryptfs as an alternativ for encfs. Take a look at the branch https://github.com/bit-team/backintime/tree/gocrypt

As far as I remember regular backups to a local attached fileystem is working fine. Reverse encrypting and syncing the cryptfiles to a remote host was working as well. Just the "on the fly" decrypting of filenames and logs is not yet implemented. The founder of gocryptfs added a special socket where BiT can read/write json for this.

[buhtz]

Sounds like light at the end of the tunnel and I'm to pessimistic here. 😄

Maybe we should think about attracting developers for that specific feature the same way we plan to do with the translators (#1473).

[RRPollack]

I started to implement gocryptfs as an alternativ for encfs. Take a look at the branch https://github.com/bit-team/backintime/tree/gocrypt

I'm interested in following your progress. Could you push your changes to a branch as you go?

[emtiu]

I agree with @buhtz about the deprecation of EncFS. It's not going to get any better, and encryption software that hasn't seen a release in 5 years is ancient and dangerous.

I can't contribute to the inclusion of gocryptfs, but it should technically make for a good drop-in replacement.

[Germar]

I'm interested in following your progress. Could you push your changes to a branch as you go?

I don't have time for further development, sorry

[RRPollack]

I don't have time for further development, sorry

Ah, my mistake. The English language is prone to such misunderstandings. :-P

I guess I'll take a look at the existing gocrypt branch myself. I'm a retired software engineer with many years of C/C++ among other languages, but I'm new to Python so it may take a while for me to spin up on it.

[Germar]

I've no professional IT background, just taught my self Python to improve BiT. But I'm happy to assist if you have questions

[buhtz]

I guess I'll take a look at the existing gocrypt branch myself.

Warm welcome!
We also have a mailing list (see README.md) if you have questions about the team and organizational aspects or anything else.

[buhtz]

I propose to open a separate Issue about removing EncFS to make it clear to other users. In short the issue would tell that EncFS is deprecated from now and the last release with EncFS would be somewhere in the year 2025 within the Debian 13 release. After that it will be removed.

[emtiu]

I propose to open a separate Issue about removing EncFS to make it clear to other users. In short the issue would tell that EncFS is deprecated from now and the last release with EncFS would be somewhere in the year 2025 within the Debian 13 release. After that it will be removed.

I think an Issue on Github is not enough for this. There should be a message inside BackInTime itself, included in one of the coming releases. Maybe on the configuration page, but a popup message would be better.

Backups are often very long-running setups for people, running for years without touching the configuration. So many people would probably not notice the EncFS deprecation until it's "too late", and their setups stop working.

[buhtz]

Yes, of course. That was also my intention to implement a pop up for this.

[Nikratio]

Drive-by comment since I stumbled upon this thread: perhaps S3QL might be another potential EncFS replacement in this context? While not prominently advertised, it supports storing the encrypted data on an SSHFS mountpoint too (not just in cloud storage services).

[buhtz]

Dear Nikolaus,
thanks for your reply.

perhaps S3QL might be another potential EncFS replacement in this context?

Looks interesting. The upstream repo seems actively maintained. But looking into Debian repos it doesn't look that good. Migration is blocked because of python-dugong which itself is archived (by you?) and unmaintained.

Are there plans to make s3ql stable again and migrate it into Debian "stable"?

And looking into your "setup.py" there is a lot of google stuff in it. Why is that? Don't look attractive.

[Nikratio]

Recent S3QL versions no longer require python-dugong.

I am not aware or involved in plans for Debian packaging.

Do you mean the dependencies on the 'google-auth' and 'google-auth-oauthlib' Python modules? That's used by the Google Storage backend to, well, connect to Google Storage. Not sure I understand your concern though - this is open-source Python code just like, say, apsw or requests.

[buhtz]

Recent S3QL versions no longer require python-dugong.
I am not aware or involved in plans for Debian packaging.

I opened a ticket there.

Do you mean the dependencies on the 'google-auth' and 'google-auth-oauthlib' Python modules? That's used by the Google Storage backend to, well, connect to Google Storage.

But why should Back In Time users want to connect to Google Storage? They just need an encrypted snapshot on there local machine, on an USB-storage device or a NAS in there own local network.

[Nikratio]

Do you mean the dependencies on the 'google-auth' and 'google-auth-oauthlib' Python modules? That's used by the Google Storage backend to, well, connect to Google Storage.

But why should Back In Time users want to connect to Google Storage? They just need an encrypted snapshot on there local machine, on an USB-storage device or a NAS in there own local network.

I didn't mean to imply that they need it. If the data is stored on the local machine, the Google Storage code paths are not used and the google-auth Python modules not needed (not sure if you can get away without installing them at all, there may be a few top-level imports that need to be commented out for that to work).

[buhtz]

Closing the issue because of #1549 (mark EncFS as deprecated). When creating the deprecation message we will provide summarized information about the EncFS situation and how to replace it to users and potential contributors.