I’m experimenting with using syncthing on an e4crypt folder. If the kernel’s key retention service does not contain the key used to encrypt the folder, then the files will either be unreadable, or even worse, reading will return the wrong content (I believe that this was the case at least for older implementations of e4crypt). I fear that this could cause to undesired sync behavior, e.g. data loss.
I therefore request a per sync-folder based feature, which, when enabled, instructs syncthing to only sync the folder if a certain magic file (e.g.
.syncthing) is readable and returns the expected content (e.g.
syncthing). I would even consider a even a more generic callback mechanism, where syncthing can be configured to invoke a configurable binary with the sync folder’s path as argument before every sync/scan action, and abort any action if the binary returns with an non successful exit status.
Syncthing already checks for the presence of
.stfolder in the folder root. If that file doesn’t exist, the sync will be cancelled. It’s intended to find out if a folder is mounted or not. Maybe you can write a script that adds/removes this file depending on the folder state.
I believe that the
.stfolder will show up in e.g.
readdir() even if the sync folder is not decrypted. Hence we need to explicitly check for the existence and correct content of a magic file.
The file names are not encrypted? How does the decryption work anyway, does it mount the decrypted version of the folder on top of the encrypted one? Or could you select a different mount point?
I think that e4crypt is content-encryption only for ext4, like the encryption of NTFS, i.e. no meta-data like filename, size, permissions are encrypted.
A “simple” way could be that the syncthing binary does not only check for the existance of
.stfolder but also if it has magic content.
Yeah, we could do that, possibly, in the v0.13 transition. If you want this, describe the need in a ticket on Github (and then, preferably, implement it. ;))
Submitted as Safeguard against encrypted folders not having been unlocked · Issue #2737 · syncthing/syncthing · GitHub
Can’t promise anything wrt the implementation, but I definitely have a need for this (and thus maybe the motivation to work at some point on it).