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.)
title:null
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}
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.
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
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 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
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
also:
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
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 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.
thanks for the update.
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.