Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- 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 (). 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. () The error being received is: "Input is not valid base64-encoded data." I've tracked this down to getting the secret from secret storage (). 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 secrets - but can confirm on secrets. Steps to Reproduce (with referenced extension - so far): 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) Upgrade vscode to view the connection explorer and it will error when attempting to pull the secret from storage.
can you help me triage this. Not sure who owns it.
was the above steps tested with snap build or Debian build ?
Snap
The problem is that encryptionService was not working with snaps before as seen in , with we made some changes to our native dependency 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 before retrieving it (not sure if this is possible unless the extension could retrieve the stored data outside the service)
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?
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 in your project and read the secret directly using the service will be: (exactly) and then the account is whatever your key is. Once you get that secret value, store it back using the 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).
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
those steps didn't work for me, I was signed after installing that snap <img width="979" alt="image" src="https://user-"
updated to a newer stable build liked above. Can you share whats in GitHub Authentication Output pane?
doesn't seem to work for Will need to investigate further but don't think this needs to be a candidate.
Maybe this revealed other issue - but I can confirm with 1.67.0, my extension appears to be working again.
and now I am seeing (in 1.67.1) a new error "Cannot get password"
Can confirm the issue from Github Authentication log fails with the error
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.
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 on the builds page) - Open it, log in to anything (GH/MSFT for settings sync for example) Close vscode Now install the stable build that is built on my branch () (all this branch does is revs the version to 1.69) Open it, and verify that your login persisted across versions
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.
maybe my message: 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.
Thanks, so right now the password hasn't gotten migrated, and right now we are getting the , 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.
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. 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.

Related discussion:
text: async $getPassword(extensionId: string, key: string): Promise<string | undefined> { const fullKey = await this.getFullKey(extensionId); const password = await this.credentialsService.getPassword(fullKey, key); <del> const decrypted = password && await this.encryptionService.decrypt(password); </del> <ins> if (!password) { return undefined; } let decrypted: string | null; try { decrypted = await this.encryptionService.decrypt(password); } catch (e) { this.logService.error(e); // If we are on a platform that newly started encrypting secrets before storing them, // then passwords previously stored were stored un-encrypted (NOTE: but still being stored in a secure keyring). // When we try to decrypt a password that wasn't encrypted previously, the encryption service will throw. // To recover gracefully, we first try to encrypt & store the password (essentially migrating the secret to the new format) // and then we try to read it and decrypt again. const encryptedForSet = await this.encryptionService.encrypt(password); await this.credentialsService.setPassword(fullKey, key, encryptedForSet); const passwordEncrypted = await this.credentialsService.getPassword(fullKey, key); decrypted = passwordEncrypted && await this.encryptionService.decrypt(passwordEncrypted); } </ins> if (decrypted) { try {