Extensions SecretStorage issue: Input is not valid base64-encoded data.

[Borvik]

Does this issue occur when all extensions are disabled?: No

• VS Code Version: 1.66.1, 1.66.2
• OS Version: Ubuntu 20.04.4

So the issue I'm having is as an extension developer (ckolkman.vscode-postgres).

I've had users report an issue that I have tracked back down to vscode - I can confirm the issue on the above versions, but don't know the full extent on other os versions. (Borvik/vscode-postgres#196)

The error being received is: "Input is not valid base64-encoded data."

I've tracked this down to getting the secret from secret storage (https://code.visualstudio.com/api/references/vscode-api#SecretStorage).

I use the SecretStorage api to securely store credentials used by my extension. The api docs don't seem to indicate a change - but something appears to have changed (whether by design and the docs need to change, or by introducing a bug).

The issue does not appear to affect vscode 1.66.0 - reverting to that version allows it to work.

I do not know whether it affects whether it affects storing secrets - but can confirm on getting secrets.

Steps to Reproduce (with referenced extension - so far):

1. In vscode 1.66.0 - with extension, create a db connection with pwd to store creds (without pwd won't use store creds so it won't use the SecretStorage)
2. Upgrade vscode
3. Try to view the connection explorer and it will error when attempting to pull the secret from storage.

[dbaeumer]

@jrieken can you help me triage this. Not sure who owns it.

[deepak1556]

@Borvik was the above steps tested with snap build or Debian build ?

[Borvik]

Snap

[deepak1556]

The problem is that encryptionService was not working with snaps before 1.66.1 as seen in #116690, with 1.66.1 we made some changes to our native dependency #146390 that now enabled the encryption service for snaps as well. So previously unencrypted data are thrown as error.

Migration:

1. At the encryption service layer, encrypt before decrypting for snaps
2. At the extension level, store the secrets again with 1.66.1 before retrieving it (not sure if this is possible unless the extension could retrieve the stored data outside the service)

[Borvik]

Ok, that may explain the issue, and I can confirm this is not broken on Windows.

Is there a way in the extension to detect installs via snap?

[TylerLeonhardt]

I have a fix^^ out for this. It will be included in 1.67 which should be released early next month. If you want to workaround this, first catch the SecretStorage Error and do one of two things:

• Ask the user for the thing you stored in SecretStorage again. Easiest to implement... inconvenient for the user.
• Temporarily (just for 1.66) include node-keytar in your project and read the secret directly using getPassword(...) the service will be: vscodeckolkman.vscode-postgres (exactly) and then the account is whatever your key is. Once you get that secret value, store it back using the SecretStorage API to prevent future errors. Very inconvenient for you, but the user doesn't have to do anything.

Personally, I recommend the first one, because the second one can be very tricky... and you probably generally wanna be robust if getting the secret fails (like if the user locks their keyring for some reason... keyrings are very tricky).

[TylerLeonhardt]

Verification (on Linux):

• install stable Snap v1.66.2
• Log in to GitHub for settings sync or extension
• Close vscode
• Update to latest snap (v1.67.0)

When you launch VS Code, you should still be logged in to GitHub

[Borvik]

❯ sudo snap install ./code-stable-x64-1650429998.snap
error: cannot find signatures with metadata for snap "./code-stable-x64-1650429998.snap"

[connor4312]

@TylerLeonhardt those steps didn't work for me, I was signed after installing that snap

[TylerLeonhardt]

@connor4312 updated to a newer stable build liked above.

Can you share whats in GitHub Authentication Output pane?

[TylerLeonhardt]

doesn't seem to work for @connor4312. Will need to investigate further but don't think this needs to be a candidate.

[Borvik]

Maybe this revealed other issue - but I can confirm with 1.67.0, my extension appears to be working again.

[Borvik]

and now I am seeing (in 1.67.1) a new error "Cannot get password"

[deepak1556]

Can confirm the issue from #147515 (comment)

Github Authentication log fails with the error Cannot get password

vscode/src/vs/workbench/api/browser/mainThreadSecretState.ts

Line 70 in 113287c

throw new Error('Cannot get password');

[TylerLeonhardt]

Ok I have a fix for this. Unfortunately due to the nature of this fix, I was unable to migrate secrets from older versions forward... but at least going forward, we shouldn't see any issues where secrets can't be decrypted after an update.

[TylerLeonhardt]

Verification is weird but here it is:

• On Linux remove all VS Code stables snaps or debs
• Now install the latest unreleased main stable candidate snap (Like 3cfcfa9 on the builds page) - snap install --dangerous --classic ./path/to/code.snap
• Open it, log in to anything (GH/MSFT for settings sync for example)
• Close vscode
• Now install the 3c318d3 stable build that is built on my branch (tyler/rev-version-for-fun) (all this branch does is revs the version to 1.69)
• Open it, and verify that your login persisted across versions

[Borvik]

Ok, just got the update to 1.68 - this is still an issue.

I'm not familiar with your merge process, but it looks like the PR that was linked here for excluding from the snap package was closed without merging. Is this still coming?

It's almost been 2 months since my extension has been working properly for Snap users.

[TylerLeonhardt]

@Borvik maybe my message:

Ok I have a fix for this. Unfortunately due to the nature of this fix, I was unable to migrate secrets from older versions forward... but at least going forward, we shouldn't see any issues where secrets can't be decrypted after an update.

wasn't clear. You will see this issue in the 1.68 update. However, going forward, you shouldn't see it. 1.69 should not have this problem.

[Borvik]

Thanks, so right now the password hasn't gotten migrated, and right now we are getting the Cannot get password, if I understand correctly in 1.69, this issue should disappear - will it still attempt to decrypt the password and then error, or will it just starting working.

If it's going to error, what should I tell the users of my extension? I would assume that the password would have to be re-entered and then it would get stored in the new way and start working.

[TylerLeonhardt]

will it still attempt to decrypt the password and then error, or will it just starting working.

Ah that's a good point... I did not clear the password after the fact. I should do this. That password is essentially dead at this point so it should be cleaned up.

I would assume that the password would have to be re-entered and then it would get stored in the new way and start working.

Yes that's correct. If you overwrite the password using the SecretStorage API you should be good to go. I think this is generally a good practice to handle when SecretStorage doesn't return an expected result because there are a lot of layers all the way down to the OS that need to work.