proton-bridge
proton-bridge copied to clipboard
No keychain available
Issue tracker is ONLY used for reporting bugs with technical details. "It doesn't work" or new features should be discussed with our customer support. Please use bug report function in Bridge or contact [email protected]. "Bridge is not able to detect a supported password manager (pass or secret-service) ..."
Expected Behavior
Should us kwallet or pass (both installed) to save keyword(s);
$ dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep secrets
string "org.freedesktop.secrets"
Current Behavior
Error message suggesting to quit or restart
Possible Solution
Support kwallet
Steps to Reproduce
- Install and run protonmail-bridge
- Error message pops up
Version Information
Bridge Quebec v3.1.2 Latest
Context (Environment)
Debian 11 with KDE
@monkeyjunglejuice according to previous reports in #359 , this should be working. Can you verify if kwallet has the secrete service handling enabled?
I have the same problem in POP_OS 22.04 so it does not look solved to me. Password manager is Seahorse 41.0
@julienlarena Can you post the output of the command from this post: https://github.com/ProtonMail/proton-bridge/issues/359#issuecomment-1469670126
Note that Gnome Keyring, kwallet (ubuntu 22.10 or newer ) and keepass xc are verified to be working.
Hello. My apologies. I should have edited my comment earlier: I figured out the problem over the week-end and it was due to some outdated/corrupted entries in my keychain. I erased everything and re-installed the Bridge. Everything runs smoothly now. Thanks a lot. Cheers, J.
@monkeyjunglejuice, for the record. I don't know which version of KWallet comes installed on debian 11, but the according to our experiments not all versions of Kwallet support the secret service integration. We noticed that on ubuntu 22.04 Kwallet does not have support for this. It works fine on 22.10 after the feature is enabled.
It seems that the standard secret key management on Linux is gpg-agent
.
For exemple, Emacs, Git and Pass use gpg-agent
internally…
KWallet or Gnome-keyring are not at all Linux standard secret key management, they are desktop specific/oriented software.
gpg-agent
use internally pinentry
which can be configured by the command update-alternatives --config pinentry
in order to use the desired pass-phrase entry system :
- KDE Wallet (
kwalletcli
) - GNOME 3 PIN or pass-phrase entry dialog (
pinentry-gnome3
) - FLTK-based PIN or pass-phrase entry dialog (
pinentry-fltk
) - GTK+-2-based PIN or pass-phrase entry dialog (
pinentry-gtk2
) - Qt-based PIN or pass-phrase entry dialog (
pinentry-qt
) - minimal dumb-terminal PIN or pass-phrase entry (
pinentry-tty
) - OpenPGP (smart)card authentication dialog window for X2Go Client (
pinentry-x2go
)
So, using gpg-agent
or pinentry
you don't need to worry about coding multi pass-phrase entry support.
The app can use the secret service at the moment, but the following warning is still in the codebase
// linux_helper.go
if _, err := execabs.LookPath("gnome-keyring"); err == nil && isUsable(newSecretServiceHelper("")) {
helpers[SecretService] = newSecretServiceHelper
} else {
logrus.WithField("keychain", "SecretService").Warn("Keychain is not available.")
}
which is misleading, since the SecretService could be provided by gnome-keyring, keepassxc, kwallet, and who knows who else (I am working on another secret service provider myself). As the first message suggest one should check if the interface org.freedesktop.secrets
is registered.
@A6GibKm the DBus secret service is provided by a different implementation which is checked right above that code.
if isUsable(newDBusHelper("")) {
helpers[SecretServiceDBus] = newDBusHelper
} else {
logrus.WithField("keychain", "SecretServiceDBus").Warn("Keychain is not available.")
}
That specific check is for fallback implementation via libsecret .
The problem is that if you have a secret service provider which is not gnome-keyring the warning will suggest the keychain is not available when it truth it is, or at least I see this message on my system.
Could you elaborate a bit more on what do you mean by fallback implementation via libsecret? Libsecret just calls the secret provider via DBus and does not use gnome-keyring directly, nor it needs it to be present.
EDIT: Additionally, the presence of gnome-keyring does not really indicate anything, you can have it installed and not have its daemon running, or not have it installed and have some other daemon providing the secret service.
That fallback is specifically for gnome-keyring. I think there may have been some issues in the past when gnome-keyring would not work correctly.
I agree that the warning message could be improved.
Still failing for me with Kwallet, I opted to use Seahorse for this and that worked fine. I'd love to see kwallet actually work with this.
This might be related to https://bugzilla.redhat.com/show_bug.cgi?id=2276060#c0 (per https://github.com/flathub/ch.protonmail.protonmail-bridge/issues/135#issuecomment-2066632311).
Relevantly, is the undermentioned empty for all of you?
I expect that at least one of the two options should be prefilled.