Test our usage of Electron safeStorage APIs and review docs

[TylerLeonhardt]

Refs: #185677

• Linux @rzhao271
• Linux @lramos15
• Linux @alexr00

Complexity: 3
Roles: Developer, Engineering Manager
Authors: @TylerLeonhardt, @deepak1556

Create Issue

---

This iteration we've moved from keytar to using Electron's safeStorage API for encrypting secrets. This test plan item is testing a couple of scenarios that user may run into and trying to make sure they have the tools in mind to troubleshoot.

This TPI will work best with Ubuntu.

Scenario 1: "We couldn't recognize your environment"

Picture this, you're using some obscure desktop environment and we don't detect it because it's not super common. VS Code should do two things:

• allow you to use a weaker encryption that safeStorage provides (and this persists)
• allows you to read the troubleshooting docs

To fake this, download the latest Insiders targz, extract it, and run:

env -u XDG_CURRENT_DESKTOP -u DESKTOP_SESSION -u GNOME_DESKTOP_SESSION_ID ~/Downloads/VSCode-linux-x64/bin/code-insiders --verbose --vmodule="*/components/os_crypt/*=1"

Then turn on settings sync and go through the flow. You should get a modal that tells you about your "unknown" environment. Try both options (note, the docs should go to vnext branch for now).

If you do the docs option, you should be taken to the docs but are still logged in. That's because your secrets are still stored in-memory. If you quit and relaunch VS Code the same way, that log in state should be gone.

When you do the weaker encryption option, make sure it saves password-store to the file opened when you run Configure Runtime Arguments. This means that if you kill the process and restart it using the same command, it should not show you the modal and instead should "just work" as you expect.

Scenario 2: "Ubuntu has a weird issue, open the troubleshooting guide"

Picture this: your system isn't setup properly and your keyring isn't working as expected... but we know you're running in a GNOME-like environment. We can tell you to just go check out the docs for assistance.

NOTE: make sure you delete the password-store property generated in the argv.json... and kill for VS Code for now...

This is an easier scenario because what we're gonna do is put the Keyring in a locked state... So, open the Passwords & Keys app (aka seahorse) and click the 🔓 next to the Login keyring. That will lock this keyring.

Now start VS Code as normal... hitting cancel on the million modals that pop up asking you to unlock the keyring... don't do it!

Sign in to Settings Sync (keep hitting cancel on the OS modal asking you to unlock the keyring) and what you should eventually get is a notification that will bring you to the troubleshooting guide.

Conclusion

Our goal is to have a nice place to start enumerating docs. Linux will undoubtably have more unique ways to be misconfigured, so at least we are starting somewhere...

We're looking to make sure we help when we can and the docs make sense.

[alexr00]

I didn't get a modal for scenario 1, I just got this:

I used device login to authenticate.

[deepak1556]

@alexr00 can you attach the logs generated in the terminal from env -u XDG_CURRENT_DESKTOP -u DESKTOP_SESSION -u GNOME_DESKTOP_SESSION_ID ~/Downloads/VSCode-linux-x64/bin/code-insiders --verbose --vmodule="*/components/os_crypt/*=1"

[deepak1556]

@TylerLeonhardt the logs from @alexr00 looks good,

6049: 0627/120427.662568:VERBOSE1:key_storage_util_linux.cc(54)] Password storage detected desktop environment: (unknown)
6049: 0627/120427.662830:VERBOSE1:key_storage_linux.cc(122)] Selected backend for OSCrypt: BASIC_TEXT
6049: 0627/120427.662933:VERBOSE1:key_storage_linux.cc(142)] OSCrypt did not initialize a backend.

[deepak1556]

The check here looks incorrect

vscode/src/vs/workbench/services/secrets/electron-sandbox/secretStorageService.ts

Line 69 in ac34ea3

if (provider === KnownStorageProvider.keychainAccess) {

, shouldn't it be provider === KnownStorageProvider.basicText ?

[alexr00]

Marking my testing as complete as Scenario 2 worked as expected. Please @ mention me in the bug for #186239 (comment) and I will verify it!

[TylerLeonhardt]

@deepak1556 os right. It should be basic text... I forgot to change that back while I was testing on macOS

[TylerLeonhardt]

PR out here: #186346

Once this goes in I'll fire off another Insiders so this TPI can be tested

[TylerLeonhardt]

New insiders released.

[rzhao271]

Suggestion: because the verbose flag causes there to be a lot of output, would it make sense to suggest storing that info into a file?

I was able to get the "locked collection" string, though 👍

$ ~/Downloads/VSCode-linux-x64/bin/code-insiders --verbose --vmodule="*/components/os_crypt/*=1" > run.log 2>&1
$ grep locked run.log
[47408:0627/114250.985588:VERBOSE1:libsecret_util_linux.cc(169)] Dummy store to unlock the default keyring failed: Cannot create an item in a locked collection
[47408:0627/114251.984576:VERBOSE1:key_storage_libsecret.cc(73)] Libsecret lookup failed: Cannot create an item in a locked collection

[deepak1556]

@rzhao271 thanks for the feedback, you can use --verbose --vmodule="*/components/os_crypt/*=1" --log-file=<absolute-path>/chrome.log to capture runtime logs in a file.

[alexr00]

Since I'd already done part of this I went back and verified Scenario 1 with the fix.