[nly]

Here's a question: why isn't there a de facto desktop independent password/key/secret manager for Linux? The Linux kernel has userland crypto apis built-in, why aren't we using them? At most, only the manager/permissions UI should be desktop dependent.

[krakensden]

There is- it's called libsecret, and it's used as a cross-platform backend for both the Gnome & KDE secret managers, which are 'just' guis for it. I don't actually know if it uses the Linux kernel's apis, but it's supposed to do a pretty good job.

[mhogomchungu]

The biggest issue with libsecret and with KWallet is that once a wallet is opened by one application,every other application can get all the contents of that opened wallet.

In GNOME,the wallet is opened by the login manager and that means all the contents of the wallet are available to all processes run from the logged in user account.

KDE refused to have the above behavior of the login manager opening the wallet and hence after login,there must be atleast one application that will have to open the wallet and then the behavior will be the same as libsecret.

Lots of people who use these two storage systems are not aware of the above.

I dont like the above behavior as i want each application to manage its own private wallet and i created lxqt_wallet[1] to give me the behavior i want.

The project also supports libsecret and KWallet for those who prefer these backends.

[1] https://github.com/mhogomchungu/lxqt_wallet

[zanny]

The UX of kwallet is awful, and everyone I put on KDE I always use a blank wallet password so they are not badgered by "enter password to unlock wallet" prompts.

Yes, its insecure to have the user session act as an unlock on a cryptographic store like that. It looks like lxqt_wallet is even worse on that front in terms of UX - yes, its more secure for every program to have its own secret stores and require prompts to unlock them, but average desktop users just want to login and have that unlock their secret stores, pretty much like Gnome does it.

What you really want is MAC on secrets. Applications that add to the secrets database get implicit access to those secrets in the future, but first access should require user permission before an application can start accessing your credentials for other accounts. You don't really need anyone to reinput a password, just prompt users "Kfoo wants to access your account [e-mail], allow?" with allow / deny choices, or make it an option in the wallet GUI.

You could probably even integrate it into current MAC solutions. Make it a VFS somewhere in var, and have your distro ship sane defaults like letting the sanctioned im client (both are based off telepathy nowadays) access the secrets store on a whitelist of domains, like @gmail, @chat.facebook.com, etc.

[mhogomchungu]

> It looks like lxqt_wallet is even worse on that front in terms of UX - yes, its more secure for every program to have its own secret stores and require prompts to unlock them, but average desktop users just want to login and have that unlock their secret stores, pretty much like Gnome does it.

lxqt_wallet supports 3 backends: kwallet,libsecret and internal one that gives the behavior i explained above.

Each backend has its pro and cons and the project lets the user pick which one works best for them.

There need to be a general purpose secure storage system that can accommodate users who wish to not have their secrets that are meant to be used by only one application be exposed to all other applications.

[nly]

KWallet in KDE4 doesn't seem to be using libsecret. Is this a KDE 5.x thing?

[dd9990]

It's being called KSecret Service afaik (https://barlog.rusu.info/valentin/blog/?p=411).

[runiq]

And it still uses libsecret under the hood.

[jryan49]

I use pass and pass-dmenu since I don't use a DE. http://www.passwordstore.org/

[tinco]

I wonder if there's a definitive list somewhere of what features operating systems should have in order to be proper for running a generic server or desktop.

There's so many blurry lines there. I agree that a secret store is best done as a system level service, but it's so hard to standardize on one api, and yet so easy for a shitty one to become de facto (I.e. X.org).