Plugin triggers desktop keyring unlock popup on load

[fdev31]

Since commit ce06fd1 each time the plugin is loaded I get a "password keyring" unlock popup.
The plugin works as expected (meaning this operation wasn't needed, same as in 3.0.0), but it's very annoying.

[AntoineGS]

Hmm this commit only updated the LSP, which is an external dependency, so there is not much I can do.
You could open an issue here on the official LSP repo.

[rickswe]

Same here, I had to disable the plugin.

[AntoineGS]

Reposting what I posted on the LSP Issue here;

I threw an LLM into the js files and it found this as the reason (which makes sense):
Starting with v1.505.0, on every LSP startup, the new code:

1. Calls initializeSecretStorage() before starting the LSP listener.
2. Loads @github/keytar.
3. Calls getPassword() using:
- Service: copilot-language-server
- Account: oauth-token-key
4. Creates and stores a 32-byte master key if none exists.
5. Uses that key to AES-GCM encrypt cached OAuth tokens.

Looks like setting GITHUB_COPILOT_AUTH_TOKEN_ENCRYPTION=false as an env var is the only way around it.
I also found this with more info.

I am not sure what the best course of action is, turning off token encryption would match the previous behavior but that would be disabling a safeguard against token theft :(

[fdev31]

Reposting what I posted on the LSP Issue here;

I threw an LLM into the js files and it found this as the reason (which makes sense):
Starting with v1.505.0, on every LSP startup, the new code:

1. Calls initializeSecretStorage() before starting the LSP listener.
2. Loads @github/keytar.
3. Calls getPassword() using:
- Service: copilot-language-server
- Account: oauth-token-key
4. Creates and stores a 32-byte master key if none exists.
5. Uses that key to AES-GCM encrypt cached OAuth tokens.

Looks like setting GITHUB_COPILOT_AUTH_TOKEN_ENCRYPTION=false as an env var is the only way around it.
I also found this with more info.

I am not sure what the best course of action is, turning off token encryption would match the previous behavior but that would be disabling a safeguard against token theft :(

If the token is already read from "some place" (environment variable or file or anything), it is not making it safer to save it once more somewhere else... what is the logic behind the current flow?

[AntoineGS]

The encryption key is stored safely behind the keyring, which is then used to decrypt sensitive information (AFAIK it's only the token for now). So even if the sqlite database containing the token gets copied, the token cannot be used without the encryption key.

[fdev31]

The encryption key is stored safely behind the keyring, which is then used to decrypt sensitive information (AFAIK it's only the token for now). So even if the sqlite database containing the token gets copied, the token cannot be used without the encryption key.

Ok, but that's still not necessary... I guess it would make sense if the user was interactively asked for its key, but in case the key is already provided by environment or config it doesn't make any sense to store it once more.