https://bugs.kde.org/show_bug.cgi?id=410457
--- Comment #6 from Ivan Čukić <ivan.cu...@kde.org> --- This will be a wall of text with some potential future hope at the end ;) > Why is this not a use-case for plasma-vault? The use-case for Plasma Vault, as said before, is to provide 'safe' containers on top of the usual protections available in Linux. > This makes no sense because the default backend (cryfs) The answer here is two-fold. Vault is not meant to be a do-all UI for cryfs or gocryptfs (otherwise, there would be no point in creating Vaults when Sirikali exists). Vault is a system for [[see first paragraph]] that uses well established encryption mechanisms like cryfs and gocryptfs to implement the [[see first paragraph]]. Now, I have nothing against syncing the encrypted data to the cloud. That part does not collide with Vaults use-case. What does collide with Vaults use-case is keeping Vaults open for long periods of time. As a real-world analogy, imagine a Plasma Vault is a wall safe where people keep their valuables. You just don't keep the wall safe open for as long as you are at home, and you don't keep the access code written on a paper in your office. To make the analogy complete wrt the cloud, when you move houses, you don't will not mind the safe being transfered from one house to another without your supervision (assuming it is unbreakable and unstealable without the access code) but safe transfer is not really the reason *why* you got the safe in the first place. > While I think this would be an interesting project, it doesn't fit my > use case. My cloud is a simple file storage. I know. The reason I mentioned git+gpg is that it is as easy to open a gitlab/github/... account as dropbox. I do agree it can be a hassle since most users already have dropbox or something similar. But it would provide quite a more portable (non-vendor-locked) solution to the same problem of end-to-end encryption. Portable in the sense that changing a provider would be trivial (be it an existing git provider, or just a random server that you have ssh access to - that does not even have to have a git server installed on it). > 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. Let me explain what I meant. If you set up home encryption using something like cryfs as the backend (so, FUSE-based like Vault, not FDE), you'll have a directory /home/.myuser.enc (for example) and /home/myuser. The fact that /home/myuser is mounted and the data is accessible does not stop you from syncing /home/.myuser.end to the cloud. So encrypted data is the only thing that is transmitted over the network. This does not even need to be a full home encryption, it can be a normal directory /home/myuser/Dropbox/_encrypted_data which you set to be mounted on login to /home/myuser/MySecureDocuments. > 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. Consistency *is* important. But, still, less important than security and privacy. At least for Vault. To be honest, and this is not me being facetous, if I wanted to enforce consistency, I'd rather remove the password saving for encrypted drives than add it to Vaults. If KWallet (and alternatives) were safe, I would probably consider allowing password storage. > Linux and Plasma are all about freedom and giving the options. > To refuse users use-cases seems off in this philosophy. Uh, this old chestnut. :) This is not true. Plasma and KDE software do provide a lot of configuration options to the user, but this is not our philosophy. Especially not when privacy and security are concerned. We've been under some fire over the years because of this (running UI apps as root, html messages in kmail, ...) but while I do like to be able to configure everything in general, I (and most of KDE devs) would never put configurability over security and privacy. > Nobody will be force to use this option when it is there, so it > won't hurt anyone, but only help some :) Sadly, this is not true. Most people don't understand cryptography well. (heck, most developers don't - there are 'enterprise' end-to-end encrypted cloud solutions that use worse encryption than encfs). I tried to make Vaults safe for users that have no idea what they are doing and that don't have the time to read a 10 page PDF on what encryption provides and what it doesn't. Adding options that don't hurt if they are not used means adding features that can hurt somebody. And when those options are in the software that focuses primarily on privacy, those options look like they don't hurt privacy. After all 'KWallet keeps passwords encrypted, so it must be safe' or 'Gnome Keyring even encrypts the data being sent between the Keyring and the application, so it must be even safer'. To make a bad analogy, I've recently had a request to add a password recovery mechanism to Vaults. That would be convinient, and would be a nice option to have for forgetful users. This would be quite insane to add on my part. The point *is* not to be able to access the data without the password. Ever. Your request is, of course, not as problematic as the above one, but I hope you get what I'm trying to say. Now to end on a more positive note. There were/are some plans to make the Vault implementation reusable from other applications (to extract its guts into a separate library). This would allow easily creating something that covers this use-case you have - for example as a page in the System Settings (and it would allow also some cool things for KMail and other applications that want encrypted storage...). But Vaults is not going to be a one-UI-to-rule-them-all. -- You are receiving this mail because: You are watching all bug changes.
