Atom Integration with KDE (using kwallet)

[thommierother]

Current Atom release 1.28.x does not use the kwallet password repository in KDE. Instead atom calls gcr-prompter from Gnome and then starts gnome-keyring-daemon. But on a KDE system (plasma 5) normally there is no Gnome keyring, all passwords are stored through kwalletd instead. There should be a connector to kwallet and also a possibility to select the password manager through config.

[rsese]

Thanks for reaching out!

The issue template information is helpful for us when triaging issues - if you can add the template information to this issue we can re-open or if you can open a new issue with the template filled out, that would be super helpful.

In particular, in what context are you seeing this, through the GitHub package (https://github.com/atom/github/)? Then what happens on KDE, is there an error of some kind?

Possibly related though it's been closed so it would be great to know more about what you're describing x-ref: https://github.com/atom/node-keytar/issues/17

---

We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.

Thanks for understanding and meeting us half way :grinning:

[thommierother]

@rsese: if you tell me how I can access the issue template either through the browser or atom, I could use it ;-) - until that, here are my answers to your questions:

in what context are you seeing this? Atom 1.29 x64 as provided by SUSE through RPM package

Then what happens on KDE, is there an error of some kind The issue appears if you store GitHub login information in atom. The data are stored in a local gnome keyring, where the KDE environment already has a keymanager (kdewallet database). The popup for the gnome keyring data delays the startup and there is no information that atom does NOT use the standard KDE environment here. People get confused if they already have a central password manager - there is no need for a gnome keyring file on KDE.

Functional Requirements

1. Add detection for KDE environment
2. When operating on KDE, save locally stored github login data in the kwallet database instead of a gnome keyring

About https://github.com/atom/node-keytar/issues/17 The mentioned patches/PRs (from @jalcine and @jathpala - dated back to 2015/16!) are not present in the current release 1.29 although this issue has been closed

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

[rsese]

Hiyo @shiftkey :wave:! Your comments in https://github.com/atom/node-keytar/issues/74 (i.e. https://github.com/atom/node-keytar/issues/74#issuecomment-415401345 and https://github.com/atom/node-keytar/issues/74#issuecomment-456153037) seem relevant, is this a dupe of https://github.com/atom/node-keytar/issues/74?

[thommierother]

@rsese I can't commit any code here, but if there is something to test for the node-keytar on linux with KDE (SUSE), I could invest some time ;-)

[shiftkey]

@rsese I think this comment is key, based on my understanding of the KDE ecosystem https://github.com/atom/node-keytar/issues/74#issuecomment-456153037

[rsese]

Thanks @shiftkey, that sounded like the same issue but wanted to double check :bow: So we'll go ahead and close as a duplicate of https://github.com/atom/node-keytar/issues/74 if you want to subscribe there @thommierother but the issue seems blocked for now as described in https://github.com/atom/node-keytar/issues/74#issuecomment-456153037 unless you're describing something different @thommierother?

[thommierother]

No, this was my intension, #74 describes it correctly. Just for info a reference link describing a possible roadmap on the KDE side, although no one seems to work on it now: https://community.kde.org/KDE_Utils/ksecretsservice

[thommierother]

Re-opening for current 1.57 Does anyone know if there has been some activity on this? From my understanding of the atom architecture, this need to be implemented in the atom core, not with an additional package.

[ninioArtillero]

I'm having the same problem, and for what I see this has been around for a while. I don´t like the fact that the only solution to keep persistent login information is to install gnome-keyring.

[vladimiry]

I don´t like the fact that the only solution to keep persistent login information is to install gnome-keyring.

It's not the only solution. Besides gnome-keyring, it's at least keepassxc, pass, bitwarden, and likely kwallet-secrets as these tools also implement the org.freedesktop.secrets interface (see https://freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-api-0.1.html for details).

[thommierother]

The root cause is a missing API on behalf of kwallet. But the integration of the interface is "in progress" and probably close for a release:

KDE Bugzilla " Release a working version of KSecretService" https://bugs.kde.org/show_bug.cgi?id=313216

Merge Request for org.freedesktop.secrets DBus API initial support https://invent.kde.org/frameworks/kwallet/-/merge_requests/11