Unknown or unsupported transport 'disabled' for address 'disabled:'

[ahmadnassri]

getting the following error and I can't seem to figure out how to further debug this

const keytar = require('keytar')

keytar
    .getPassword('foo', 'bar')
    .then(console.log)
    .catch(console.error)

results in:

Unknown or unsupported transport 'disabled' for address 'disabled:'

apt show libsecret-1-dev results in:

Package: libsecret-1-dev
Version: 0.18.5-3.1
Priority: optional
Section: libdevel
Source: libsecret
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Installed-Size: 2,273 kB
Depends: libsecret-1-0 (= 0.18.5-3.1), gir1.2-secret-1 (= 0.18.5-3.1), libglib2.0-dev
Homepage: https://wiki.gnome.org/Projects/Libsecret
Tag: devel::library, role::devel-lib
Download-Size: 181 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian stretch/main amd64 Packages
Description: Secret store (development files)
 Library for storing and retrieving passwords and other secrets.
 It communicates with the "Secret Service" using DBus.
 .
 This package contains the development files.

[shiftkey]

@ahmadnassri it's not clear to me whether you're running this in an Electron app, or in a Node script, or which Linux distro you're running it on.

The best clue I've found for this error was this mailing list thread which shows the same error message with some more context:

(chromium:30285): LIBDBUSMENU-GLIB-WARNING **: Unable to get session bus: Unknown or unsupported transport “disabled” for address “disabled:”

With keytar you also need some sort of backing store to respond to requests for credentials from your app - libsecret is just the agnostic way it requests credentials. On Linux distros we recommend gnome-keyring, and it's not clear from the details if something is missing in your setup.

[imlucas]

@shiftkey I just hit this as well trying to upgrade to 4.x from 2.x.

Upgrading to mainline keytar@4.3.0 Travis build using electron-mocha: https://travis-ci.org/mongodb-js/storage-mixin/jobs/457606818#L579

9d6821d switched to libsecret (👏) so I'm confused about why gnome-keyring is still mentioned/required?

The fork I'm using was an early version of that PR that. Just curious as we'll need to update our installation docs https://docs.mongodb.com/compass/master/install/

[shiftkey]

9d6821d switched to libsecret (👏) so I'm confused about why gnome-keyring is still mentioned/required?

#53 has more context on this, but basically this means keytar is not tied to a specific backing store - anything that knows how to use the Secret Service API can be used here.

I still recommend gnome-keyring as I know that works with the libsecret API, but there might be other options out there.

[imlucas]

@shiftkey cool thanks.

Looking at that mailing list thread (mentions --media-router=0), appears to be Chromecast's fault?

Going to play around with some of these media related flags

[imlucas]

Ok. I've finally gotten to the bottom of this. Only took... well too many days I'd like back :D

This comment on travis-ci/travis-ci/9262

The dbus-launch in master travis setup may be enough for node.js, but was not enough to make electron work. Using xvfb-run or xvfb-maybe was also not enough to fix this problem.

Here's the finally recipe that ended up working out for me:

before_script:
  - |
    export DISPLAY=:99.0; sh -e /etc/init.d/xvfb start; sleep 3;
    export NO_AT_BRIDGE=1; # Don't use dbus accessibility bridge
    eval $(dbus-launch --sh-syntax);
    eval $(echo -n "" | /usr/bin/gnome-keyring-daemon --login);
    eval $(/usr/bin/gnome-keyring-daemon --components=secrets --start);
    /usr/bin/python -c "import gnomekeyring;gnomekeyring.create_sync('login', '');";
script:
  - npx electron-mocha

[shiftkey]

Closing this out as we've figured out how to workaround the issue. Thanks for the snippet @imlucas!

[baruchiro]

@shiftkey Now I'm trying to do that in WSL2 but it didn't work.