This would be very useful. Are there any news about this?

There are already better tools for this use-case. You should encrypt user's home directory, or better, create an encrypted /home partition. The same goes for PAM - if you want encryption that integrates with login, Vault is not the solution.

Integration with KWallet is out of the question as it would render Vaults useless. Anyone who has access to a computer with the user logged in would have access to all Vaults as getting the password from KWallet is as simple as invoking a single command in shell. There is no point in keeping something encrypted if the encryption key is easily accessible.

Vaults are meant and designed to be small encrypted containers _under_ your regular security (be it a simple login or an encrypted drive etc.) that are in the locked state for as much as they can be. That is the reason closing a vault can be easily done and easily automated (activit switching, kde connect commands) while requiring an explicit action to open them.

As for cloud storage, the encrypted data can be synced without the vault being open.

> Integration with KWallet is out of the question as it would render Vaults useless.

Not in the use case of a cloud, not wanting to give unencrypted files to the cloud provider.

> There is no point in keeping something encrypted if the encryption key is easily accessible.

This is no problem since the encrypting key will only be stored on my machine and will not be accessible by the cloud provider.

---

I use a plasma vault for encrypting my files before they are seen by the cloud client so that it uploads the files encrypted. I do not care about locally encrypting the files. The whole purpose of this is that the cloud provider / server does only get encrypted versions of the files.

For this usecase storing the password unencrypted on my computer is okay. It will not destroy the purpose of the vault and will still do the job.

> There are already better tools for this use-case. You should encrypt user's home directory, or better, create an encrypted /home partition.

Encrypting the /home directory will not help at all with this. (I'm already using FDE anyway.)
The cloud client runs after user login and syncs the files it sees in its directory. They will be unlocked at that time, even with encrypted /home. So the cloud client would upload the unencrypted files. This would solve nothing. Another layer in between is needed. For example by using plasma-vault ;)

---

> Vaults are meant and designed to be small encrypted containers [...] that are in the locked state for as much as they can be.

Yes I would want to keep them closed while not used. (I have multiple vaults on my cloud for different things.)
This way, they eat up less memory of my machine and I'm a little more safe against accidental changes by me.

But currently, closing and later reopening a vault is not very user friendly. I always have to type my password, which is not very fun when your password is mad of many random chars/symbols.
It would be much faster if I could just open/close vaults with one click.
For that, an option to remeber the password is required.

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.

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.

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.


P.S. Bug status is meant for developers to classify bugs. While we all appreciate the discussion, there is no point in reopening a bug unless a developer reopens it because the discussion made them see the problem in a different light.

(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 :)

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.