On Mon, 2024-05-06 at 07:45 +0000, [email protected] wrote: > 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 think a major use case of automated backups (with BiT and other backup tools) is: --> Just mount the encrypted target device/folder to create the backups and then lock it again. This eg. protects the backups better against trojans that encrypt all your devices to blackmail you. But this use cases requires to automatically mount the encrypted device (= unlock using a secret credential). BiT supports many standard credential managers of Linux via the "keyring" Python package but to unlock the encrypted device BiT needs to know how (= which encryption container) and implement this in Python code And since we do not implement the encryption logic itself our risks of doing something wrong are manageable. So I think 1. unless we drop above uses case we need to support encryption (container) in BiT 2. we should still support EncFS for legacy reasons (users still using it) but give a clear warning about the deprecation (and that it is insecure). Also we should link a FAQ entry how to migrate to another encryption container. 3. For encryption that is transparent to BiT (eg. udev-based mounting of external devices) we should add documentation links (as @Hakan proposed: "[...] Like full documentation for creating encrypted volumes on Linux [...]" _______________________________________________ Bit-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: [email protected]
