Use kwallet for the time being...

https://github.com/frankosterfeld/qtkeychain

I think there are two approaches to this:

• The resource requests the password from another service (so i.e. directly interfaces with kwallet or so....)
• The application provides the password for the resource:
  • The resource emits a notification that it requires a password
  • The application provides the password through another command (after requesting it from the user or a wallet)
  • The resource holds the password in-memory for its lifetime (which might be very short or also longer).

In it's most basic form Kube should request the password from the user, hold it in memory, and pass it to the resource which will itself hold it in memory. This way the password will need to be entered every time kube is started, but not every time the resource is started. The password will only remain in memory and in no configuration file.

As an improvement from this, Kube can then store/load the password from an available keyring (e.g. through qtkeychain).

This will require a protocol between application and resource where:

• The resource notifies that it requires a secret
• The application reacts to that notification by requesting the secret somehow and providing it to the resource
• The application directly providing the secret if it already has the secret available.

OAuth/OAuth2 or any other token based mechanism could work similarly in that the resource has to ask kube to i.e. visit some url to perform authentication. The resource could then probably hold on to the token directly though.

As a second step we could start using the gpg key that we will setup with every account to encrypt credentials. This would serve as a portable, but kube specific keyring.

https://developer.pidgin.im/wiki/PlainTextPasswords

First implementation:

• Client registers a callback with libsink to provide the password.
• Resources send a command requesting the password and wait with logging in until the password is available.
• Callback provides requested password by sending it via command to resource.
• The resource caches the password in-memory for duration of process
• The client caches the password in-memory for the duration of the process (because resources can die in-between).
• The client simply requests the password from the user on every start.

What we have now is that the password get's cached locally and is distributed to resource. What we miss is:

• Secure storage of the passphrase (so you can unlock a seperate keyring instead)*
• A password dialog that deals with accounts that require multiple passwords
• A sane mechanism that deals with the multi-account situation. Right now we just move into the login screen whenever we activate an account that has a locked keyring, and the login screen cannot be escaped. For proper multi-account support we probably want to make this more opt-in:
  • An account could in principle be usable without password, just offline only. Whether that is useful is questionable though, it probably makes sense to keep unlocking the keyring a requirement for access (this will then also work if we decided to actually encrypt local caches etc).
  • Right now the account switcher is inside the mail-view which, cannot be accesses from the login screen. Either the account switcher needs to change, or the login screen needs to get an account switcher.