also just noticed that if a key is retrieved from keepassxc, vscode 1.80 rejects it (not using it), whereas the previous 1.79.2 does accept it without problems

reverting to vscode 1.79.2 fixes all the issues (no message, settings sync key is not rejected)

Can you try these steps to see if it works:

• Run the vscode command Configure Runtime Arguments
• in that JSON file, add "password-store": "gnome-libsecret" at the root of the JSON structure

Restart VS Code and see if it works.

In 1.79.2 we used keytar to store things in the keyring. It's been archived so we switched to using an Electron API built on Chromium features instead. My proposal should tell VS Code that you want to use libsecret aka the Secret Service to store secrets... but if it doesn't work we probably have some work to do in Chromium.

Adding it to the runtime arguments works, but then immediately it asks me to delete the old entry, and new undescriptive entries show up named Chrome Safe Storage Control and Chromium Safe Storage instead of the old vscodevscode.github-authentication/github.auth

Edit:
after a closer look at the entries, it seems like Chrome Safe Storage Control is a dummy entry for chrome to detect something
and Chromium Safe Storage seems to store something, but i am not sure what it is, it is smaller than the old vscodevscode.github-authentication/github.auth entry
also both are now request at startup instead of just one

So the "Safe Storage" part is correct. The way Chromium does things is different than keytar. Rather than storing the entire secret in the keyring, it generates an encryption key, encrypts the secret, and stores the encryption key in the keyring. The secret is encrypted at this point, and can be stored anywhere. We store these encrypted secrets in VS Code's global user storage along with other application state.

So that explains why the size is much smaller than before. Now, I am slightly surprised that it's called Chromium Safe Storage and not Code Safe Storage. I use macOS and I see that it says Code Safe Storage (well Code - Insiders Safe Storage in my case since I'm using Insiders)... It's suppose to use the application name before Safe Storage . @deepak1556 any thoughts on this?

just to fully make it clear, i am using https://aur.archlinux.org/packages/visual-studio-code-bin if that makes a difference

@deepak1556 unrelated to that, I think since modern kwallet supports libsecret & since libsecret is agnostic of desktop environment, when we detect KDE I think it would be a good idea to also check libsecret.

Now, I am slightly surprised that it's called Chromium Safe Storage and not Code Safe Storage

Chromium declares libsecret schema with application name as an attribute whereas the label of the entry is a static constant that currently cannot be configured by embedders. We can polish this but the current state does not cause any harm since entries will be unique per application name.

I will merge this to #187338

I'm getting this error despite putting that line into ~/.vscode/argv.json

and new undescriptive entries show up named Chrome Safe Storage Control and Chromium Safe Storage instead of the old vscodevscode.github-authentication/github.auth

And for us who have been studying democracy?? we do not have any google/chromium spyware.

I'm having the exact same issue:

You're running in a KDE environment but the OS keyring is not available for encryption. Ensure you have kwallet running.

I do use kwallet on KDE Plasma though and not keepassxc. Is this expected behaviour, for me to get this bug too?

Is there any workaround, and are we expecting a fix for this? It's really time consuming for me to reauthenticate to GitHub through the browser each time I spawn a new repo/VS Code session.

@irfanhakim-as that is not expected. Can you open a new issue with the output of the command mentioned here in our docs?

https://code.visualstudio.com/docs/editor/settings-sync#_troubleshooting-keychain-issues