Question: Possible running secret-service in WSL2

[ryan-dyer]

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.18922.1000]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)
  Attempting to get gnome-keyring working in WSL2.
  Running:
  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic
  I have installed dbus, libsecret-1.0, libsecret-tools, and gnome-keyring.
  Specifically I am trying:

 secret-tool store --label=test key value
Password:
** Message: 12:19:21.107: Remote error from secret service: org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.Secret.Collection' on object at path /org/freedesktop/secrets/collection/login
secret-tool: No such interface 'org.freedesktop.Secret.Collection' on object at path /org/freedesktop/secrets/collection/login

• What's wrong / what should be happening instead:
  Would assume I should be able to store the secret. Ultimately I'm attempting to use secret-service as the backend for aws-okta (https://github.com/segmentio/aws-okta).

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).
  https://gist.github.com/ryan-dyer/8cd8fe458139475f1f8b495fe99f42a6

• For WSL launch issues, please collect detailed logs.

See our contributing instructions for assistance.

[therealkenc]

The usual dbus session goodness that is normally in place with a common Ubuntu graphical install with xdm/gdm/lightdm (or similar) isn't in place with a (typical) WSL setup. You've also have no systemd-logind alive.

Your question is basically this reddit.

I made an effort to prove that answer wrong (it is) but too lazy on a Canada Day to take it to completion. Including as far as I got here for posterity so I don't lose it. Maybe someone highly motivated will iterate.

Other way to go is get systemd running (ref #994) and fire up xrdp. After logging into the session, you'll almost certainly get a nice pretty credentials popup out of secret-tool, because gnome-keyring-daemon will be living in its happy place.

Calling defeat for the day on a CLI solution tho. Bonne chance.

[oryandunn]

@therealkenc thanks for taking a shot at this. I tried following along with your solution, but ran into one issue after another, and I don't have the knowledge base to make it further than you did.

My frustrations follow.. I'm not sure why we need all that just to store a password securely. For now, I think my script will just have to prompt each time for the password. It was curious to me why plain text netrc files were a thing, and they unfortunately make some sense given the state of things...

From all the research I've done, this seems to be an issue with using secret-tool on any headless Linux system (but I could be wrong). If that's the case, it's quite shocking that a command line only solution for something as basic as credential storage doesn't exist. I also tried using the python3 keyring module, but that had it's own issues, and I suspect it'd ultimately boil down to the same errors that secret-tool runs into, since the python keyring uses the same secret service api.

[therealkenc]

this seems to be an issue with using secret-tool on any headless Linux system (but I could be wrong)

Ref this (although it is pretty stale circa 2015). It would take a drill-down into libsecret to figure out what it would take.

[therealkenc]

Calling defeat for the day on a CLI solution tho. Bonne chance.

The OP scenario works out of the box with WSLg. It would be a pretty deep rabbit hole to get a text-based (tty) keyring password prompt set up. I am sure it can be done; people probably do it with cloud scenarios. Punt getting that much working on WSL to discussion as it is a userspace thing. There wasn't a WSL actionable on this one, notwithstanding feature-request GUI solution gnome-keyring. If you fire up Firefox (or similar) you get the same sort of keyring prompt.