What is the provider of org.freedesktop.secrets for KDE Plasma 5?

The app showed this error on first startup. What is the recommended solution? I’m running Arch Linux KDE. Thank you. (BTW, it’s nice that the app makes it so easy to report issues like this. Looks like your team is doing a great job developing this app.)

content: Unexpected Error: PlatformException(Security Access Error, Failed to lookup secret: The name org.freedesktop.secrets was not provided by any .service files (2) (g-dbus-error-quark), {domain: g-dbus-error-quark, code: 2, message: The name org.freedesktop.secrets was not provided by any .service files}, null)
OS: linux Linux 5.13.4-arch2-1 #1 SMP PREEMPT Thu, 22 Jul 2021 20:46:28 +0000
App Info: AuthPass (1.9.2+1834) [design.codeux.authpass.linux]}
Device: {name: Arch Linux, version: null}

afaik KDE uses ksecrets as secret service implementation. If you can’t find that one, you might try your luck with gnome-keyring :thinking:

maybe this helps as well:


so either ksecretsservice or kwallet :thinking:

Here’s a current answer from a KDE developer, so I consider this to the be official answer. He said:

KWallet still doesn’t implement org.freedesktop.secrets, and KSecretService is dead.

Therefore, I guess we should warning people not to use KSecretService…

However, I also found this solution: KeePassXC Secrets Service

It seems a bit weird to use KeePassXC just to get AuthPass to work well on KDE, but since I already have KeePassXC installed (and I like it), this doesn’t bother me. I’m trying this solution now. Hopefully it proves to be a good solution.

KeePassXC Secrets Service actually does work. It works well and it allowed me to set up AuthPass Cloud.

Okay, that’s funny. :slight_smile: thanks for the update.

Out of curiosity, is this requiring to unlock KeePassXC with a master password first, or do you only need to install it?

The only reason this is necessary is because we need a location to store auth tokens, in case you are using a cloud storage… (without cloud storage this wouldn’t be necessary actually). On literally all other platforms (except Web) there is a way to let the system store it encrypted (Android KeyStore, iOS and MacOS Keychain, Windows Credentials Management API) - So when searching for an alternative for linux, I only found the secret service APIs. I hoped those would be universal. But it seems on KDE there is no standard implementation :roll_eyes:

On the Web/Browser I simply use the (unecrypted) localStorage (since in the browser all auth tokens - ie. cookies - are stored unecrypted anyway…). Maybe I should switch linux to be unencrypted as well. I think there are many applications which store their tokens in a plaintext ~/.blubb file … like docker in ~/.docker/config.json

or - do you have pass installed? Not sure if this is a default application :thinking: might be an alternative we could use…

I somehow want to avoid having users require another “master password” besides the one for the password files :slight_smile:

It depends. I can set KeePassXC to launch automatically at system startup (actually user login). I created a separate database for the secret service functionality. I can, if I wish, have that database unlock with only a key file. So, in theory, I think I can make this a seamless or almost seamless experience.
If KDE’s KWallet provided this secret service, the process would be similar. KWallet requires either its own password after the user logs in, or changing some settings to make it unlock the wallet automatically.

I noticed that I was able to dismiss the error and I believe I would have been able to continue using AuthPass without the secret service provider. But, as you said, when I tried to set up the cloud functionality, AuthPass could not proceed until I had a secret service provider.

Yes, it seems to be a deficiency in KDE. I have subsequently learned* that some KDE users are installing Gnome’s secret service provider. But since I already had KeePassXC installed, I’m fine with my solution. I actually like it a lot because it provides more transparency and control. It’s a very good implementation of the secret service in my opinion.

I don’t really know the security implications of that… but I think every Linux desktop distro is going to have GnuPG installed (it is part of the default GNU package). Maybe you could leverage that instead? GnuPG is definitely the most used encryption tool on the Linux platform.

This repo looks a little old, but maybe it will point you to something useful: see link 2

This is not dart, but it is up to date and widely used:

  • GitHub - mitya57/secretstorage: Python bindings to Freedesktop.org Secret Service API - link 3


  • secret_service - Rust - link 4
  • gnome keyring daemon - Using Secrets API with dbus-send - Stack Overflow: see link 7.

I do have pass installed. Unlike GnuPG, it doesn’t come pre-installed on most distros. It is definitely not a default app. On my system, the installed size for pass is 46.6 KB, which is nice. (However, it has a dependency on GnuPG.)

One more idea is to use openssl. This package is required by many apps including LastPass – and critically, by systemd. Since every major Linux distro uses systemd, depending on openssl doesn’t seem like a problem. I routinely use openssl on the command line to do simple crypto stuff.

  • How to Easily Encrypt and Decrypt Files and Directories in Linux With OpenSSL - see link 6

Yes, I agree with that.

Links I had to remove due to forum limits:

  1. github dotcom /Foundry376/Mailspring/issues/681
  2. github dotcom /damondouglas/gnupg.dart
  3. github dotcom /mitya57/secretstorage
  4. docs - dot- rs /secret-service/1.0.0/secret_service/
  5. removed
  6. makeuseof dotcom /how-to-easily-encrypt-and-decrypt-files-and-directories-in-linux/)
  7. stackoverflow /questions/63475223/using-secrets-api-with-dbus-send)

Even if it is installed, I doubt many users will be using it / configured a private key. So AuthPass would have to create a new key and ask the user to choose a password… and it will only be used for AuthPass… so no idea how that would be better than doing the whole encryption within authpass…

Not sure about what exactly you are referring to. That library and stackoverflow question just asks how to access secret service api through d-bus … which is exactly what AuthPass is currently doing.

There is already quite a bit of encryption going on in AuthPass :rofl: That’s not the problem. The problem is having a secret key (ie. password) with which to encrypt the data with. There is no need to encrypt anything, when you don’t have a secret key to encrypt it with. Keychain/KeyStore/Secret service use the account password of the logged-in user or some other form of authentication (like fingerprint) to generate a secret key.

So there are only three options…

  1. Use a secret key provided by the system
  2. Ask the user for a password
  3. Store in plaintext

fwiw… as far as i can tell, chrome stores cookies encrypted with the password peanuts (if it can’t use the keyring or similar: chrome/browser/password_manager/encryptor_posix.cc - chromium/chromium - Git at Google ), so maybe just skipping encryption altogether isn’t that bad anyway. Or also just “obfuscate” it with some hard coded secret :man_shrugging: