What if i want to use an app relying on this library on wslv2 and have no ui/gnome/seahorse?
markussiebert opened this issue · comments
Really struggling using an app that uses this library on wslv2.
Installed keyring, but have no gnome, no gkeyring, no seahorse ... how can i create a keyring via the cli?
seahorse tells me:
(seahorse:23589): Gtk-WARNING **: 23:33:20.817: cannot open display:
gkeyring isn't maintained anymore
It would be nice if you could give me a hint, how i can initialize the default keyring via a terminal without x and gnome.
Update:
Found:
https://www.reddit.com/r/ProtonMail/comments/81zmto/linux_keyring_issues/
microsoft/WSL#4254
Ok, after installing some dbus, gnome keyring etc. i think this is working, even if it is no good solution:
dbus-run-session -- zsh (or your prefered sh)
gnome-keyring-daemon --unlock
<your password> return, ctrl+d
... use your program that relies on this library ...
if anyone knows how to "automate" this, please let me know
ok, best thin i found til now:
Add this to your bashrc, or zshrc or ...
if [ "$DBUS_SESSION_BUS_ADDRESS" = "" ]
then
exec dbus-run-session -- zsh
else
echo "$(/lib/cryptsetup/askpass 'Password: ')" | gnome-keyring-daemon --unlock
fi
!!! modify the exec statement to your usecase !!!
Cons:
- one extra sh session?
- password prompt on every sh session
- extra dbus session for every sh
Don't know if it's helpful but you can see how we do on travis: https://github.com/zalando/go-keyring/blob/master/.travis.yml (headless linux env).
The question is if you really need a keyring in the environment you're running. What is the purpose of the app, what is it storing in the keyring? Maybe a password could be passed in a different way for headless cases?
Ok, I'm confused. I understand that you're not using TravisCI any longer, but GitHub's own CI, and your link above ought to be updated to https://github.com/zalando/go-keyring/blob/master/.github/workflows/go.yml
However, as you so well commented on this file, your past usage of Python's gnomekeyring is deprecated in any Ubuntu version greater than 16.04. While I imagine that it can be backported somehow, it seems that it's too much trouble in order to get a working keyring without installing the whole X11/Gnome environment — which is certainly not appropriate for a server-side installation (both my case and the OP's).
Your question about the purpose of such a usage of go-keyring is, with due respect, irrelevant. Your package is used by many other software packages upstream, which use it as a convenient form of storing all sorts of keys or tokens (for example, I'm using Pydio Cells, which has a command-line utility that can store a token for remote authentication purposes. It uses go-keyring as its abstraction layer, and it works flawlessly — I've even managed to successfully tweak the code to use your in-memory storage for operating systems without keyrings, such as FreeBSD).
I admit I haven't been using go-keyring lately, and the last time I did, I was still stuck to Ubuntu 16.04 LTS, and everything worked just straight out of the box, no need to worry much about it. Similarly, my Mac has no issues whatsoever, either. But on a Ubuntu 20.04 LTS server, this is another story! I would have thought that there is a better/easier way of initialising the keyring somehow; I guess I'm spoiled by SSH and GnuPG (or, well, the general-purpose macOS keychain).
Anyway, I digress; I'll keep digging for a simple solution — similar to the one you used for Ubuntu 16.04 — which will work under 20.04 and possibly future versions as well.
If not... well, I wonder if there isn't a way to have go-keyring create the keyring on its own, as opposed to simply getting and setting keys in an existing keyring? That's just a thought; probably there are very good reasons why this isn't possible to do...
Replying to myself... it seems that I had basically everything to run the solution/hack proposed by @Markus7811 — all that I was missing was
pip install secretstorage dbus-python
Once that was in place, I could run the commands suggested by @Markus7811 and
keyring --list-backends
will list
keyring.backends.SecretService.Keyring
(among a couple of others, but that's the important one)
keyring is also installed with the secretstorage package, as a command-line utility (Ubuntu 20.04 LTS will place it in the default /usr/local/bin/ location).
To partially automate the issue, I used echo 'my-password' | gnome-keyring-daemon --unlock which seems to work. Of course, it means that this particular password is now in plaintext somewhere on a script — not a good thing. But it works.
Still, I find it utterly terrible to have installed several MBytes of useless X11/Gnome libraries only to get a default keyring installed and operational...
I'm also running into this issue and haven't found a workaround. I started with a fresh instance and installed all the dependencies but my code that works other OSes fail. One difference from @GwynethLlewelyn is the backends:
jberi@jberi-desktop:/mnt/c/Users/Jonathan$ keyring --list-backends
keyring.backends.chainer.ChainerBackend (priority: -10)
keyring.backends.fail.Keyring (priority: 0)
Any suggestions? I'm a bit of a linux n00b, definitely a WSL2 n00b.
More details of what I have installed:
$ uname -a
Linux jberi-desktop 4.19.84-microsoft-standard #1 SMP Wed Nov 13 11:44:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ dbus-run-session --version
dbus-run-session 1.12.16
$ gnome-keyring-daemon --version
gnome-keyring-daemon: 3.36.0
$ pip3 list
Package Version
------------------------------ --------------------
dbus-python 1.2.16
keyring 18.0.1
SecretStorage 2.3.1
service-identity 18.1.0
@beriberikix I wonder what Linux distro you chose when installing WSL2... the differences might be there, but, then again, I had never even heard of WSL before this thread, so I hardly know what I'm talking about 😹
You should be able to see what distro you have by running lsb_release -a on bash.
While Microsoft has made available several popular distros, the truth is that they have partnered with Canonical for this exciting project — the makers of Ubuntu — so it's reasonable to assume that Canonical & Microsoft will test first if everything works as it should on Ubuntu.
You would think, right??
jberi@jberi-desktop:~/zephyrproject$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
I even tried deleting my VM and set it up fresh, same issue :(
@beriberikix wrote:
You would think, right??
jberi@jberi-desktop:~/zephyrproject$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focal
Interesting. You are running Ubuntu 20.04.2 LTS. That ought to mean that everything should work under your installation... that's pretty much what I'm running as well.
I know I'm piping in very late and I'm assuming you have fixed your issue by now...
@beriberikix wrote:
You would think, right??
jberi@jberi-desktop:~/zephyrproject$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focalInteresting. You are running Ubuntu 20.04.2 LTS. That ought to mean that everything should work under your installation... that's pretty much what I'm running as well.
I know I'm piping in very late and I'm assuming you have fixed your issue by now...
It doesn't, Ubuntu relies on gnome-keyring, which relies on having gnome desktop and an X11 server installed, which WSL/WSL2 users don't* .
* WSL2 is starting to support X11 via WSLg, but it's not remotely reliable with gnome-keyring based on my testing and still has the issue of not being able to set a master keyring password without the gui.
This is still an issue for me.
HM!... I was pretty sure that my Ubuntu installation did not have X11 and/or Gnome Desktop installed — since it's a server and does not require wasting CPU + RAM in launching a GUI that will never be used. On the other hand, it's true that apt is often 'greedy' and installs way too many things before you realise what has been done...
Just because gnome-keyring had the word gnome in it, it doesn't necessarily mean that it requires Gnome Desktop to be installed. To be sure, I checked what apt-rdepends reports as dependencies (these are checked recursively):
apt-rdepends-gnome-keyring.txt
It's a long list, and it does include libx11-6 as well as libp11-kit0, but these are just the libraries — not any X11 executable. It also includes libsoup-gnome, which is a support library for Gnome apps to make HTTP calls via C, but, again, this will not install the full Gnome Desktop. There are also the odd things here and there, listed as supplemental helper apps, some of which might actually have a GUI interface (such as pinentry-gnome3, for instance), but when I searched if any of those had actually been installed — they weren't.
My conclusion is that you can run things like gnome-keyring, the Gnome DBUS, etc., all without actually relying on either Gnome or even X11.
Of course, I didn't actually test this under WSL/WSL2, and according to a reply on AskUbuntu/StackExchange, apt-rdepends may actually not be accurate. However, it errs on the side of caution, meaning that it's likely to list many more packages that were either already installed by other applications or that are not relevant for one's current setup. In my case, for example, I did not install (explicitly) pinentry-gnome3, since, as said, I don't run Gnome or X11; instead, I have installed pinentry-curses, which is the CLI-based equivalent to allow PIN entries for GnuPG. In fact, Ubuntu cleverly links pinentry to the preferred alternative (if you have both the GUI and the CLI version), so that specific keyrings can just call pinentry (if a PIN entry is needed to unlock a key), and they will get either the GUI or the CLI version, depending on what you've installed.
In my case, just having a pinentry symlinked (via /etc/alternatives) to pinentry-curses was enough for gnome-keyring to 'know' that a PIN entry application was already installed and didn't attempt to install the GUI version instead. My assumption is that similar decisions were made for other dependencies when I deliberately avoided anything with a GUI and always preferred to have CLI equivalents/alternatives; ultimately, that meant that, at the end of the day, I managed to get the Gnome keyring, the DBUS, helper applications such as pinentry etc. — all of them installed without requiring any GUI to be running.
Now, I cannot claim that my approach can be flawlessly reproduced — since I have, over time, installed so many things that I don't remember exactly what steps I took — but I would recommend that at least you give it a try. If you are reinstalling from scratch, deliberately installing Ubuntu as a server (as opposed to a desktop) may help you out to exclude any GUI-specific things from the very beginning. But, as said, I'm actually running Ubuntu on top of bare metal — things might obviously be different when using WSL/WSL2...
Good luck!