search

ProtonMail / proton-bridge

Proton Mail Bridge application
GNU General Public License v3.0
1.11k stars 145 forks source link

No keychain available #384

Open monkeyjunglejuice opened 1 year ago

monkeyjunglejuice commented 1 year ago

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 bridge@protonmail.ch. "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

  1. Install and run protonmail-bridge
  2. Error message pops up

Version Information

Bridge Quebec v3.1.2 Latest

Context (Environment)

Debian 11 with KDE

LBeernaertProton commented 1 year ago

@monkeyjunglejuice according to previous reports in #359 , this should be working. Can you verify if kwallet has the secrete service handling enabled?

julienlarena commented 1 year ago

I have the same problem in POP_OS 22.04 so it does not look solved to me. Password manager is Seahorse 41.0

LBeernaertProton commented 1 year ago

@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.

julienlarena commented 1 year ago

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.

LBeernaertProton commented 1 year ago

@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.

pivaldi commented 1 year ago

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 :

So, using gpg-agent or pinentry you don't need to worry about coding multi pass-phrase entry support.

A6GibKm commented 7 months ago

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.

LBeernaertProton commented 7 months ago

@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 .

A6GibKm commented 7 months ago

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.

LBeernaertProton commented 7 months ago

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.

Sylk commented 5 months ago

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.