https://bugs.kde.org/show_bug.cgi?id=410457
--- Comment #5 from Elias <supg...@gmail.com> --- (In reply to Ivan Čukić from comment #4) > To repeat, if you want encryption just for the cloud sync, which is unlocked > while you're logged in, Vault is not the solution. It is not Vault's > use-case. Vault is *not* going to support use-cases which blur the best > practices for its use-case. Why is this not a use-case for plasma-vault? This makes no sense because the default backend (cryfs) is mainly made for exactly this purpose. The first sentence on its website (https://www.cryfs.org/) is: "Keep your data safe in the cloud" So while cryfs is especially made for the cloud, it seems really off for plasma-vault as a frontend to not support its main functionality. In fact, cryfs and gocryptfs are perfect solutions to encrypt cloud storage. EncFS was too in the past, but is not recommended anymore due to found security issues. > One of the interesting things I've been researching recently (which might end > up as a new KDE project at one point) is git+gpg which provides a nice > end-to-end encryption. The local files are not encrypted, but they are sent > properly encrypted to a git server. This would be a good tool for your > use-case. While I think this would be an interesting project, it doesn't fit my use case. My cloud is a simple file storage. The client just copies the files over. This simple filesystem is just right, so I don't need a more complicated setup like a git server. Also, I guess you can't just setup a git server on Dropbox or Google Drive anyway, so this won't work. > As mentioned before, the alternative is to set up the usual encrypted $HOME > (or some other directory) and sync the encrypted data with your cloud > provider. This would have the benefit of gpg+git with added protection > against device theft if it is stolen while powered off. Also as mentioned before, this is not the solution for my use-case. The only thing I want to prevent is that the people having access to the server my data is stored on can not read it unencrypted. Encrypting home will bring zero benefit for this. Since the cloud sync software runs under my user after login, it will see the decrypted files and so upload them unencrypted. This does not help at all in this use-case. Also I'm already using Full Disk Encryption, so I'm already safe against device theft. --- I do not sacrifice security if the password is stored on my machine. This is fine, since the cloud provider can't access my machine where the key is, they will only get the encrypted vault / files which they can't ready without the key. Also, implementing a "save password" option would be good for consistency. Plasma does already support saving the password for for example external encrypted disks / storage. Now imagine the cloud as another "external storage" since it is exactly this. It would make sense for plasma to be consistent and support the same functionality (in this case saving the password) for all encrypted external storages the same. --- And, just to be complete, here is one last reason to implement a password save option: Linux and Plasma are all about freedom and giving the options. To refuse users use-cases seems off in this philosophy. Nobody will be force to use this option when it is there, so it won't hurt anyone, but only help some :) -- You are receiving this mail because: You are watching all bug changes.
