vscode: Allow safestorage api to detect presence of libsecret or kwallet if the desktop environment is unknown

@TylerLeonhardt the desktop env is X-Generic from https://github.com/microsoft/vscode/issues/185212#issuecomment-1605261078

@Krohitkrishna12 the flow you are seeing is expected in your case as the runtime is unable to detect the storage backend, I have kept this issue open to see if it can be addressed on the runtime side.

You have two options as workaround in your scenario,

1. Following the notification for troubleshooting, if you are able to confirm libsecret or gnome-keyring is available which you have already done then you can do

1) Open Insiders and from command palette, run `Configure Runtime Arguments`
2) Set `"password-store": "gnome"`
3) Restart and you should no longer see any error

1. Use the weaker encryption that does not use the OS keyring as storage backend if you would like just get things moving without having to debug your OS information.

@deepak1556 no but i did see the password store set to basic_text which i updated to gnome and everything seems to work as before now. Thank you for the help. i will remove and try when i update to see if the issue gets fixed.

To clarify, before opting to use the weaker encryption. Did you try "password-store": "gnome" option ?

If you had opted to use the weaker encryption, then if you open the runtime settings file via Configure Runtime Arguments there will be an entry "password-store": "basic_text". You can unset this entry when this issue gets closed to get a proper fix.

Also any way to clear the creds that vsccode currently stores with weaker encryption?

If VSCode updates to use a different storage backend then your persisted sessions will be cleared and VSCode will ask you to re-authenticate. So you don’t need to do any work to clear them out.

@deepak1556 i can continue using Weaker encryption as long as its okay to use and creds are fairly safe 😉. is there any way to reset or undo using weaker encryption so i can see if future update would fix the issue? Also any way to clear the creds that vsccode currently stores with weaker encryption?

@Krohitkrishna12 what desktop environment do you use?

i use Debian Linux 11 container in Chrome os Stable @TylerLeonhardt. I Currently overwrote the desktop environment variable from X-generic to Gnome to see if it helps. But sadly no. i dont know if reverting it back would gain anything.

I can confirm that manually setting XDG_CURRENT_DESKTOP does the trick:

XDG_CURRENT_DESKTOP="GNOME" code-insiders

Same problem here on latest insiders, however I do have XDG_CURRENT_DESKTOP set in my environment:

$ echo $XDG_CURRENT_DESKTOP
sway

I use gnome-keyring-daemon, and this all worked fine until the recent code-insiders change.

Currently I get the expected (automatic) login behavior if I do:

$ env XDG_CURRENT_DESKTOP=GNOME code-insiders 

UPDATE: After a little reading here, I realized sway might not be an appropriate setting for this variable.

Unless your work to “adjust Electron to allow BASIC_TEXT encryption for safestorage API” would allow us to do that?

Yes atleast from reading through the implementation, this will allow the runtime to use the text fallback without any need for restart or user intervention. I will confirm and get back.

Yes I’m using gnome-keyring, and it works fine with previous insiders release and with the stable release.

$ systemctl --user status gnome-keyring-daemon
● gnome-keyring-daemon.service - GNOME Keyring daemon
     Loaded: loaded (/usr/lib/systemd/user/gnome-keyring-daemon.service; enabled; preset: enabled)
     Active: active (running) since Thu 2023-06-15 12:36:32 CEST; 3h 43min ago
TriggeredBy: ● gnome-keyring-daemon.socket
   Main PID: 16317 (gnome-keyring-d)
      Tasks: 4 (limit: 67352)
     Memory: 3.5M
        CPU: 1.067s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gnome-keyring-daemon.service
             └─16317 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring

$ dpkg -l | grep gnome-keyring
ii  gnome-keyring                                               42.1-1+b2                                            amd64        GNOME keyring services (daemon and tools)
ii  gnome-keyring-pkcs11:amd64                                  42.1-1+b2                                            amd64        GNOME keyring module for the PKCS#11 module loading library
ii  libgnome-keyring-common                                     3.12.0-1                                             all          GNOME keyring services library - data files
ii  libgnome-keyring-dev                                        3.12.0-1+b2                                          amd64        Development files for GNOME keyring service
ii  libgnome-keyring0:amd64                                     3.12.0-1+b2                                          amd64        GNOME keyring services library
ii  libpam-gnome-keyring:amd64                                  42.1-1+b2                                            amd64        PAM module to unlock the GNOME keyring upon login

$ dpkg -l | grep libsecret
ii  libsecret-1-0:amd64                                         0.20.5-3                                             amd64        Secret store
ii  libsecret-common                                            0.20.5-3                                             all          Secret store (common files)

$ dpkg -l | grep -i dbus-x11
ii  dbus-x11                                                    1.14.6-1                                             amd64        simple interprocess messaging system (X11 deps)

Rolled back to version 1.80.0-1686734381 and everything works fine again. So I’m staying in that version meanwhile. If anyone needs the previous version it can be found here: packages.microsoft.com/repos/code/pool/main/c/code-insiders/code-insiders_1.80.0-1686734381_amd64.deb