Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Atom Integration with KDE (using kwallet) #155

Open
thommierother opened this issue Jun 25, 2018 · 12 comments
Open

Atom Integration with KDE (using kwallet) #155

thommierother opened this issue Jun 25, 2018 · 12 comments

Comments

@thommierother
Copy link

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
Copy link

rsese commented Jun 25, 2018

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: #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 😀

@rsese rsese closed this as completed Jun 25, 2018
@thommierother
Copy link
Author

@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 #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
Copy link

lock bot commented Feb 2, 2019

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!

@lock lock bot locked as resolved and limited conversation to collaborators Feb 2, 2019
@atom atom unlocked this conversation Feb 4, 2019
@rsese rsese transferred this issue from atom/atom Feb 4, 2019
@rsese rsese reopened this Feb 4, 2019
@rsese
Copy link

rsese commented Feb 4, 2019

Hiyo @shiftkey 👋! Your comments in #74 (i.e. #74 (comment) and #74 (comment)) seem relevant, is this a dupe of #74?

@thommierother
Copy link
Author

@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
Copy link
Contributor

shiftkey commented Feb 4, 2019

@rsese I think this comment is key, based on my understanding of the KDE ecosystem #74 (comment)

@rsese
Copy link

rsese commented Feb 5, 2019

Thanks @shiftkey, that sounded like the same issue but wanted to double check 🙇 So we'll go ahead and close as a duplicate of #74 if you want to subscribe there @thommierother but the issue seems blocked for now as described in #74 (comment) unless you're describing something different @thommierother?

@thommierother
Copy link
Author

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
Copy link
Author

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
Copy link

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
Copy link

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
Copy link
Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants