Unknown or unsupported transport “disabled” for address “disabled:”

[vladimiry]

Unknown or unsupported transport “disabled” for address “disabled:”

[vladimiry]

The link to the updated FAQ has been added to the login form (if Snap package is executed there will be one more Snap-specific bullet, see it here).

The issue remains open until a new app release is ready and the AUR package updated.

[joshirio]

Would be interesting to know if the AppImage runs on your machine to see if it is a dependecy problem or something else.

[vladimiry]

@juanjux message under the login form is going to look a little different than you saw it in previous work-in-progress build, see screenshot here #104 (comment).

[StevenDoesStuffs]

I'm definitely using keepassxc as the system keyring. I see an entry for the master password.

I'm not quite sure how to fix the error you're having though.
EDIT: Go into the application settings and enable secret service integration there first. Then go into database settings and try again.

[joshirio]

the AUR package has been updated and gnome-keyring became an optional dependency alongside org.freedesktop.secrets. Now users are free to choose the password storage backend.

[vladimiry]

Thanks, closing the issue then.

PS Maybe it's worth adding the same message you just posted here at AUR side too.

[vladimiry]

It's probably due to the node-keytar still requires the gnome-keyring dependency on KDE, see related issues:

• #34
• atom/node-keytar#132
• atom/node-keytar#74

So try to install gnome-keyring and libsecret.

By the way there is a package in AUR repo being maintained by @joshirio, it's only for the stable release channel though.

[stormsz]

hello, yes i did installed the package from the AUR repo, on my home and and in this one.
i do have the gnome-keyring package.
reinstalled, rebooted and what not. same problem.
when i call the program in the terminal without sudo it gives me:

Segmentation fault (core dumped)

the sudo problems persist.

[vladimiry]

Ok, thanks for the detailed report. I don't run KDE, so can't play around the issue for now. But I guess some app users do run KDE, so maybe someone will come up with a workaround.

[joshirio]

I'm running Manjaro KDE too and it works, but haven't applied the recent system updates, I'll test that maybe something changed and broke a dependency?

[joshirio]

@stormsz I updated the AUR package, can you check if it works now? I had another machine where it did not launch but after applying the aur update it works again. If it still doesn't work try installing libappindicator-sharp which pulls down all the mono stuff which is not really required though, that's why I left it out. Let me know

[stormsz]

hello, reinstalled from the aur, also installed the libappindicator-sharp package.
the problem still persists :| not sure what to do now....
exacly the same terminal errors.

[joshirio]

I'm out of ideas, don't know what else it could be, I have it working on a XFCE and KDE Manjaro 🤔

[stormsz]

tried manually installing the app. and ofc i got an error :c
[cunha@void` email-securely-app-master]$ yarn run electron-builder:dist:linux:pacman
yarn run v1.10.1

$ electron-builder --linux pacman

• electron-builder version=20.28.4
• loaded configuration file=/home/cunha/Documents/email-securely-app-master/electron-builder.yml
• writing effective config file=dist/builder-effective-config.yaml
• rebuilding native production dependencies platform=linux arch=x64
• rebuilding native dependency name=keytar
• rebuilding native dependency name=sodium-native
• packaging platform=linux arch=x64 electron=3.0.5 appOutDir=dist/linux-unpacked

--> Error: Application entry file "app/electron-main.js" in the "/home/cunha/Documents/email-securely-app-master/dist/linux-unpacked/resources/app.asar" does not exist. Seems like a wrong configuration.
at error (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/asar/asarFileChecker.ts:7:12)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/asar/asarFileChecker.ts:33:11
at Generator.next ()
at /home/cunha/Documents/email-securely-app-master/node_modules/graceful-fs/polyfills.js:287:18
at FSReqWrap.oncomplete (fs.js:155:5)
From previous event:
at checkFileInArchive (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/out/asar/asarFileChecker.js:78:17)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:395:13
at Generator.next ()
From previous event:
at LinuxPackager.checkFileInPackage (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:392:110)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:444:16
at Generator.next ()
at /home/cunha/Documents/email-securely-app-master/node_modules/graceful-fs/polyfills.js:287:18
at FSReqWrap.oncomplete (fs.js:155:5)
From previous event:
at LinuxPackager.sanityCheckPackage (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:431:70)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:235:16
at Generator.next ()
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
From previous event:
at LinuxPackager.doPack (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:166:165)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:112:16
at Generator.next ()
From previous event:
at LinuxPackager.pack (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/platformPackager.ts:110:95)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/packager.ts:376:24
at Generator.next ()
at xfs.stat (/home/cunha/Documents/email-securely-app-master/node_modules/fs-extra-p/node_modules/fs-extra/lib/mkdirs/mkdirs.js:56:16)
at /home/cunha/Documents/email-securely-app-master/node_modules/graceful-fs/polyfills.js:287:18
at FSReqWrap.oncomplete (fs.js:155:5)
From previous event:
at Packager.doBuild (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/packager.ts:344:39)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/packager.ts:314:57
at Generator.next ()
at /home/cunha/Documents/email-securely-app-master/node_modules/graceful-fs/graceful-fs.js:99:16
at /home/cunha/Documents/email-securely-app-master/node_modules/graceful-fs/graceful-fs.js:43:10
at FSReqWrap.oncomplete (fs.js:141:20)
From previous event:
at Packager._build (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/packager.ts:285:133)
at /home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/packager.ts:281:23
at Generator.next ()
From previous event:
at Packager.build (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/packager.ts:238:14)
at build (/home/cunha/Documents/email-securely-app-master/node_modules/app-builder-lib/src/index.ts:58:28)
at build (/home/cunha/Documents/email-securely-app-master/node_modules/electron-builder/src/builder.ts:227:10)
at then (/home/cunha/Documents/email-securely-app-master/node_modules/electron-builder/src/cli/cli.ts:42:48)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
From previous event:
at Object.args [as handler] (/home/cunha/Documents/email-securely-app-master/node_modules/electron-builder/src/cli/cli.ts:42:48)
at Object.runCommand (/home/cunha/Documents/email-securely-app-master/node_modules/yargs/lib/command.js:238:44)
at Object.parseArgs [as _parseArgs] (/home/cunha/Documents/email-securely-app-master/node_modules/yargs/yargs.js:1085:24)
at Object.get [as argv] (/home/cunha/Documents/email-securely-app-master/node_modules/yargs/yargs.js:1000:21)
at Object. (/home/cunha/Documents/email-securely-app-master/node_modules/electron-builder/src/cli/cli.ts:25:28)
at Module._compile (internal/modules/cjs/loader.js:688:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:699:10)
at Module.load (internal/modules/cjs/loader.js:598:32)
at tryModuleLoad (internal/modules/cjs/loader.js:537:12)
at Function.Module._load (internal/modules/cjs/loader.js:529:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:741:12)
at startup (internal/bootstrap/node.js:285:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:739:3)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
`

[vladimiry]

@stormsz it looks like you skipped the app build phase and jumped straight to the installation package preparing.

I'd recommend to perform it in the way similar to how CI server does it preparing the installation packages:

1. remove node_modules dir
2. execute this command yarn && yarn app:dist && yarn electron-builder:dist:linux:pacman

Before that make sure you have Node.js v10 and Yarn installed, see details in readme file.

[vladimiry]

By the way instead of executing yarn electron-builder:dist:linux:pacman you can also build it to directory running yarn electron-builder:dir. In this case you can execute the app running ./dist/linux-unpacked/email-securely-app binary without installation.

[stormsz]

hello, sorry for the late reply, i'm more of a network kind of guy, rly bad with this compiling and stuff.
so i tried to rebuild and what not.
but yarn app:dist is giving me the following error:

$ electron-builder install-app-deps
• electron-builder version=20.28.4
• loaded configuration file=/home/cunha/Documents/email-securely-app-master/electron-builder.yml
• rebuilding native production dependencies platform=linux arch=x64
• rebuilding native dependency name=keytar
• rebuilding native dependency name=sodium-native
$ ava --verbose "./src/e2e/**/*.{spec,test}.ts"

✖ No tests found in src/e2e/unread.spec.ts

EDIT: not rly sure what you mean about the appimage but if it is running this command:

yarn run electron-builder:dist:linux:appimage

i did it and it gave me no errors, but didnt started the app either.

[vladimiry]

✖ No tests found in src/e2e/unread.spec.ts

This is not an error, you need to wait just a little more and build process will be finished, you were almost there :) But if you don't want to wait, this command just builds and packages the pacman dist skipping the tests yarn && yarn clean:app && yarn build && yarn assets && yarn electron-builder:dist:linux:pacman (it's recommended to remove node_mudules before running this command).

EDIT: not rly sure what you mean about the appimage

Appimage is the portable package format, see here https://github.com/vladimiry/email-securely-app/releases/tag/v1.5.2 If you will be running it, wait for like up to minute after start since app image packages usually start slowly.

EDIT Can you also try to start the app using AUR version having the NO_AT_BRIDGE=1 environment variable set?

[stormsz]

dont know, was having errors left and right and decided to format the drive, got it working now at first try on a fresh manjaro kde, thanks a lot for the help :)

[juanjux]

I have exactly this problem in KUbuntu 18.10, using the Deb package. I've the gnome-keyring and libsecret packages installed.

(email-securely-app:25520): Gtk-WARNING **: 13:24:19.962: Theme parsing error: gtk.css:127:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(email-securely-app:25520): Gtk-WARNING **: 13:24:19.962: Theme parsing error: gtk.css:128:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(email-securely-app:25520): Gtk-WARNING **: 13:24:19.962: Theme parsing error: gtk.css:132:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

(email-securely-app:25520): libunity-CRITICAL **: 13:24:20.652: unity-inspector.vala:96: Unable to connect to session bus: Unknown or unsupported transport “disabled” for address “disabled:”

(email-securely-app:25520): libunity-CRITICAL **: 13:24:20.652: unity-launcher.vala:157: Unable to connect to session bus: Unknown or unsupported transport “disabled” for address “disabled:”

(email-securely-app:25520): libappindicator-WARNING **: 13:24:20.680: Unable to get the session bus: Unknown or unsupported transport “disabled” for address “disabled:”

(email-securely-app:25520): LIBDBUSMENU-GLIB-WARNING **: 13:24:20.680: Unable to get session bus: Unknown or unsupported transport “disabled” for address “disabled:”

[vladimiry]

I'd ask you to do the same Travis does preparing the environment for running e2e tests:

• Install these modules:
  • libsecret-1-dev
  • gnome-keyring
  • libgnome-keyring-dev
  • python-gnomekeyring
• execute such commands (the order of command execution matters):
  • dbus-launch --sh-syntax
  • echo -n "" | /usr/bin/gnome-keyring-daemon --login
  • /usr/bin/gnome-keyring-daemon --components=secrets --start
  • /usr/bin/python -c "import gnomekeyring;gnomekeyring.create_sync('email-securely-app-issue-57-login', '');"

Then try starting the app, from console first.

If it still doesn't work try starting the app with NO_AT_BRIDGE=1 env variable set, executing something like this:

NO_AT_BRIDGE=1 `(which email-securely-app)`

[juanjux]

Seems there is not package python-gnomekeyring in Ubuntu 18.10 (or later than 16.04), I also can't find any pip-installable package with that name.

[vladimiry]

That travis job runs Ubuntu Trusty.

python-gnomekeyring is needed for /usr/bin/python -c "import gnomekeyring;gnomekeyring.create_sync('email-securely-app-issue-57-login', '');" command execution which just tests that gnome keyring actually works. There should be another way to test that, but for now, try to just skip installing python-gnomekeyring and running respective test command.

PS You can also expore the keyring running https://wiki.gnome.org/Apps/Seahorse with GUI.

[juanjux]

Did everything except the last step but still have the same problem. Will try from source.

[vladimiry]

I think we then have to wait for atom/node-keytar#74 issue resolving. I don't run KDE nor the Ubuntu and so I won't be able to play around the issue on my own in the near future.

[juanjux]

Looks like it, building from source gave the same result.

[vladimiry]

I'm considering exploring an option of making saving master password with keytar optional feature. So the app will test in-runtime if keytar module supported by the system before enabling the feature.

[juanjux]

That would be a good option since I usually don't save passwords locally.

[vladimiry]

The app doesn't force a user to save the password, neither master password nor passwords of the email accounts. But it provides the option to do so.

The thing is that on some systems using keytar prevents the app to start and this is why I'm considering making keytar optional runtime dependency.

[Zypherspace]

I wonder if ESA running under Gnome could be wrapped to a flatpak. Gnome-keyring and associated framework would get packaged and run in any environment. Could also be sandboxed,

[vladimiry]

Flatpack package format is not yet supported by electron-builder tool.

[vladimiry]

@juanjux can you try starting this build? Or build your own package from sources. It's supposed to start with the master password saving feature disabled and respective log line added.

[juanjux]

It works! Thank you!

[vladimiry]

Can you look into the log file? Would like to know the error message got written there.

[juanjux]

Of couse. Sorry for the text in Spanish, I've my locale configured in that language, but I'll translate below:

[2019-02-11 10:17:57.155] [error] "keytar" module is unsupported by the system Error: Transporte «disabled» desconocido o no soportado para la dirección «disabled:»

which means:
Transport "disabled" unkown or unsupported for the address "disabled:".

[vladimiry]

So it's the original message. Thanks for confirming. Closing the issue. Made change will be a part of the next release.

[vladimiry]

@joshirio, I noticed AUR package got replaced gnome-keyring dependency with libsecret. I explicitly removed the gnome-keyring library from the system, restarted the system, installed the AUR app and got the The name org.freedesktop.secrets was not provided by any .service files error in the log file and "auto-login feature unsupported by the system"-like message in the app. So it still doesn't work without gnome-keyring, at least on my setup.

[joshirio]

I gave it a try since a user has been suggesting this change multiple times. I'll revert the change, thanks.

[vladimiry]

@joshirio I guess the behaviour might differ depending on the system/DE used. For example, I didn't try running KDE stuff but Xfce.

[StevenDoesStuffs]

@vladimiry @joshirio Hey, I am that user that has been suggesting the change. The problem is, you still need some keyring installed and active to be able to use the auto-login feature. libsecret is just the interface library for keyrings, and something still needs to be there to provide the backend for the feature to work. My suggestion to replace the gnome-keyring dependency was to make it so that those who don't want to use the feature don't have to have it installed, and people could use a different keyring if they wanted to.

[StevenDoesStuffs]

To prove my point, you can look at the "required by" section of https://www.archlinux.org/packages/core/x86_64/libsecret/ and https://www.archlinux.org/packages/extra/x86_64/gnome-keyring/. You'll notice almost all packages listing either libsecret or org.freedesktop.secrets as dependency, and almost never gnome-keyring directly.

[vladimiry]

those who don't want to use the feature don't have to have it installed, and people could use a different keyring if they wanted to.

Hi @StevenDoesStuffs, thanks for the details. It looks like misunderstanding happened since you wrote there about replacing gnome-keyring dependency with libsecret not pointing that gnome-keyring or its alternative/other-client will need to be explicitly installed for the auto-login feature to be functional.

Yes, I agree that auto-login can be considered as an optional feature since I intentionally made it optional by 18c0ca7 commit. If the feature is unavailable the app logs the error and shows the respective message in UI #104 (comment) (second/Snap point on the screenshot will be shown only for Snap package, so only first pint for Archlinux users). For sure there are many packages that list some dependencies as optional and then users have to explicitly install the specific dependency to get some feature enabled. So I could live with gnome-keyring to be listed in AUR as an optional dependency with respective description but let's hear @joshirio opinion who is the AUR package maintainer.

[StevenDoesStuffs]

@vladimiry your program actually works with anything that provides org.freedesktop.secrets, for example keepassxc, which I am using (and it works perfectly!). I believe it'd be better to list that as an optional dependency instead, as many other packages have chosen to do.

[vladimiry]

works with anything that provides org.freedesktop.secrets, for example, keepassxc

I will need to verify that myself, will report then. If it's so I think we better list them both as optional dependencies as a known/proven needed secrets interfaces kickers since I don't want to favour specific library. I write kickers since it looks like the needed secrets interface won't be lifted/enabled if there is no its implementator like keepassxc or gnome-keyring.

For example, this is how I guess gnome-keyring enables the secrets interface

ElectronMail/.travis.yml

Lines 64 to 65 in 4b4f810

	eval $(echo -n "" | /usr/bin/gnome-keyring-daemon --login);
	eval $(/usr/bin/gnome-keyring-daemon --components=secrets --start);

[vladimiry]

Removed gnome-keyring, rebooted, signed-in in keepassxs, enabled the ssh agent in the keepassxs settings, tried activating "secrets service integration" for the database as described in https://github.com/keepassxreboot/keepassxc/blob/0fd883686c05c7689bf8f074b02dcfff3a705a97/src/fdosecrets/README.md and got the enable fd.o service to access these settings message in the keepassxs ui

@StevenDoesStuffs so I guess you might be running some fd.o secret service implementations other than gnome-keyring, like maybe kwallet/ksecrets/etc and if so then keepassxs has nothing to do with auto-login feature working for you? As in my case keepassx requires something like that.

[vladimiry]

EDIT: Go into the application settings and enable secret service integration there first. Then go into database settings and try again.

Missed that setting. Yeah got it working, quite nice that keepassxs is able to act as keyring store.

@joshirio your opinion? I tend to select an option of listing both keepassxc and gnome-keyring as optional dependencies.

I'm going to add this point to FAQ (ie auto-login in the app on Linux requires either keepassxc or gnome-keyring) and then place a link to the FAQ on the screen posted here #104 (comment)

[vladimiry]

I'm going to add this point to FAQ (ie auto-login in the app on Linux requires either keepassxc or gnome-keyring) and then place a link to the FAQ on the screen posted here #104 (comment)

I think I better add quoted stuff and only then after the new app version released with extended issue description on the login screen the AUR package gets new changes. Since if we do that now without extending the login screen some users might get confused and will have to dig into the issue rather than going from the login screen straight to the FAQ.

[joshirio]

It's nice to see some progress on the linux keyring issue. Up until some time ago, the "secret service" API became the new standard for both GNOME and KDE but then, like always, things were not implemented, the new Kwallet (or what's called now) never implemented the API, making the new API in fact useless.

Since keepassxc provides that API now, it makes sense to drop the hard dependency on gnome-keyring. That dependency was introduced at that time because it was the only way to run ElectronMail with auto-login without too much hassle.

I propose to make it like chromium does.
After a new version is released with the appropriate message as @vladimiry just said in the commend above, I'll update the AUR package and set org.freedesktop.secrets as optional dependency like the chromium arch package does.

I think this is the best compromise, at the same time we warn users about the missing dependency but don't force a gnome component on users by default.