Open Tofandel opened 4 years ago
The issue for me was related to mongo-compass being unable to access https://en.wikipedia.org/wiki/GNOME_Keyring.
I tried a couple solutions online such as https://bbs.archlinux.org/viewtopic.php?id=224652 to no avail. I read that most login managers (lightdm, ssdm, gdm, etc.) will unlock it at the time of login -> I now use lightdm instead of logging into my computer from the terminal with a call to startx
and it's working okay.
There is still a wierd glitch where the first time mongo-compass is opened after login it immediately exits and subsequent versions work fine.
Same experience here. MongoDB Compass exits just one time, perhaps trying to open Gnome Keyring. Subsequent opens work fine.
Getting this issue with:
installing gnome-keyring
also solved it for me
This must be documented on the Linux Installation section
Getting this issue with:
- mongodb-compass 1.33.1-1
- endeavourOS
installing
gnome-keyring
also solved it for me
i have gnome-keyring installed but the problem persist. Did you do anything else than installing it?
Hey @pedrokuper, which OS do you have? Is it also endeavourOS?
I've got the same problem on KDE with Debian 12, already have gnome-keyring
installed as well.
Same experience here. MongoDB Compass exits just one time, perhaps trying to open Gnome Keyring. Subsequent opens work fine.
Exact same thing happens to me
Could this please be looked into? As much as I hate to be this person "bumping up" the issues, I do want to report I have been facing the same issue of credentials not being read/written from/into the keyring for at least few months now - I am pretty sure this wasn't always the case (I do have some passwords that were used by mongodb-compass saved in it) yet I haven't changed anything on my side with my setup or installed packages.
I am on Arch Linux 6.8.9.arch1-2
with mongodb-compass 1.43.0-1
package installed from the AUR.
I do use a non-standard keyring implementation (pass-secrets-git), however I have verified with other applications that make use of keyring that it fully re-implements regular secret store and its interfaces.
If there is anything I could do to help with resolving this issue, I'd be happy to help.
We are working on adding a message to signal if the secret storage can be accessed or not. We will consider updating the requirements for the linux installation as well.
Did you do anything else than installing it?
You can verify if is running:
ps aux | grep gnome-keyring-daemon
If is not running, you can try to start it manually once:
/usr/bin/gnome-keyring-daemon --start --components=secrets,ssh
and try again to see if compass would allow storing secrets. I'm not sure if more steps are necessary to make sure that the daemon can run properly.
If that would work, you may want to create a service to run the daemon at start up.
@zneix newer versions of Compass use https://www.electronjs.org/docs/latest/api/safe-storage to access the keyring. We never tested a backend different from gnome-keyring, but I would assume that any storage that announces as a valid backend would be picked up.
A minimal test script:
// testsafestorage.js
const { app, safeStorage } = require('electron');
const assert = require('assert');
app.on('ready', () => {
if (!safeStorage.isEncryptionAvailable()) {
console.error('Safe storage is not available on this system.');
app.quit();
return;
}
if (safeStorage.getSelectedStorageBackend) {
console.log('backend:', safeStorage.getSelectedStorageBackend());
}
const secret = 'MySecret';
const encrypted = safeStorage.encryptString(secret);
const decrypted = safeStorage.decryptString(encrypted);
assert.notEqual(secret.toString('base64'), encrypted.toString('base64'));
assert.equal(secret, decrypted);
console.log('OK');
app.quit();
});
npx electron testsafestorage.js
Thank you for a very straightforward reply!
I've copied & saved the script you've provided, ran it and it did print Safe storage is not available on this system.
when used with my custom backend up and running.
After that, just to eliminate possibility of there being a potential issue with the custom backend I use, I've decided to install gnome-keyring
package (which in result also was conflicting with custom backend, so I've removed it and made sure to disable & stop the systemd unit for it) - sadly that also yielded the same result:
I'm not sure if this means that I'm either missing some system library (assuming issue would be on my environment's side) or have something related to the keyring misconfigured.
I can see safe-storage API's documentation mentioning necessity of a "secret key" being available to make the function that fails for me return true
, but I don't have a clue what to do with that further nor what does "secret key" refer to specifically.
Let me know if there's anything more I can do. Cheers.
Just now, I've tried to comment-out the first if
statement and see what happens with the code;
I did get a popup with javascript exception, which was expected, but the script continued to run and a message backend: basic_text
was printed (nothing past that though, since I expected assert statements to also fail).
The reason why I mention that is because description for basic_text
value mentions following: When the desktop environment is not recognised [...]
and maybe it will be helpful to note that I do not have a desktop environment installed, but rather a window manager i3, which might behave differently and be a related cause of the safe storage not being available.
Another thing that I found after a bit of poking around is that when I start Compass with mongodb-compass --ignore-additional-command-line-flags --password-store="gnome-libsecret"
the password is picked up from and saved to the keyring just fine - even with my backend.
As well as running your script with npx electron --password-store="gnome-libsecret" testsafestorage.js
makes it work just fine, printing backend: gnome_libsecret OK
('OK' is on a new line of course) then exitting gracefully.
Note that for password-store
flag, using any value other than "gnome-libsecret"
(from the ones listed in documentation at https://www.electronjs.org/docs/latest/api/safe-storage#safestoragegetselectedstoragebackend-linux) does not yield the success.
I'm sorry for a chaos with replies, but I hope that the extra context might help to narrow down the issue.
Even more research has lead me onto the very similar issues with vscode [ 1 ], which seems like it's an issue with electron itself being unable to detect the desktop environment, which turns out to be critical towards being able to determine whether the electron application should look for gnome keyring / kwallet / etc.
I can verify that because attempting to run the script with the XDG_CURRENT_DESKTOP
environment variable being set to GNOME
, which seems to be how Electron determines the environment, makes the script work OK, as well as the MongoDB Compass itself.
[ 1 ]: https://github.com/microsoft/vscode/issues/187338 https://github.com/microsoft/vscode/issues/185212
Hello, im on Fedora 40 Workstation and have the same issue. I have gnome-keyring installed and running but its not working.
Facing similar issue here:
➜ ~ uname -a
Linux astanwar99 6.9.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 28 Jun 2024 04:32:50 +0000 x86_64 GNU/Linux
➜ ~ echo $XDG_CURRENT_DESKTOP
i3
➜ ~ mongodb-compass --version
MongoDB Compass 1.43.4
➜ ~ ps aux | grep gnome-keyring-daemon
astanwa+ 2121 0.0 0.0 311880 10876 ? SLsl 09:59 0:00 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
This works though:
mongodb-compass --ignore-additional-command-line-flags --password-store="gnome-libsecret"
Thanks @zneix. Basically, you're saying that fix will come from electron right? For time being, can we set these flags in launch options or any config file for compass?
Hey everybody, we're trying to figure out if we can apply this option automatically in some cases, but trying to do a solid reproduction takes awhile, so bear with us please while we're doing this. For the time being, making sure that you have gnome-keyring installed and passing --ignore-additional-command-line-flags --password-store="gnome-libsecret"
option explicitly should help you work around the issue. @zneix thanks a ton for debugging this and finding the root cause!
I run debian stable with i3wm pretty much stock and was running into this issue. I can confirm the running with the additional flag fixes it. If you need help with the repro let me know but thats a very simple vm to create that can reproduce this.
--password-store="gnome-libsecret" adding this fixed the issue for me. Thanks
I was trying to run MongoDB Compass using the desktop file in /usr/share/applications
with additional command-line flags. I wanted to use the --ignore-additional-command-line-flags --password-store="gnome-libsecret"
flags to ensure Compass would correctly access the credential store.
In the original desktop file, the Exec
line included an additional %U
at the end. However, no matter where I placed this %U
in the command, MongoDB Compass wouldn’t accept the --password-store
flag, which meant it couldn’t access the credential store.
As a workaround, I removed the %U
from the Exec
line and added my desired flags. Now, Compass launches correctly from the desktop entry with access to the credential store.
If anyone has experience with this and knows whether removing %U
could compromise security or functionality, I’d appreciate any insights.
Mongodbcompass: 1.20.5 Kubuntu: 19.04
None of my connections/settings are stored, when I restart the app my favorite or recent connections are lost
I'm getting this error:
WIth a bit of research I found a similar issue https://github.com/Foundry376/Mailspring/issues/681
sudo apt install gnome-keyring
solved the issue but adding it as a dependency would be a good idea