Remove stale secrets after decryption failure - #324014
Conversation
📬 CODENOTIFYThe following users are being notified based on files changed in this PR: TylerLeonhardtMatched files:
|
There was a problem hiding this comment.
Pull request overview
Fixes an ordering issue in BaseSecretStorageService.get() where a decryption failure could leave a stale encrypted value in storage until a later sequenced delete() task ran, allowing callers to observe get() completing before the cleanup finished.
Changes:
- On decryption failure, removes the persisted value synchronously within the same per-key sequencer task (instead of queueing an un-awaited
delete()). - Refactors deletion logic to share a
removeValueFromStorage(...)helper so the failure path anddelete()use the same scope selection. - Adds a regression test ensuring stale persisted secrets are removed before
get()resolves and that subsequentget()calls do not attempt decrypt again.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/vs/platform/secrets/common/secrets.ts | Performs immediate in-sequencer storage removal on decryption failure and refactors delete removal via a helper. |
| src/vs/platform/secrets/test/common/secrets.test.ts | Adds a regression test verifying stale persisted secrets are removed before get() resolves after decryption failure. |
|
|
@microsoft-github-policy-service agree |
|
CLA signed. Could someone from the VS Code team please approve the workflows and review this PR when available? |
|
Thanks! |
71ae1f4 to
8dd3e6b
Compare
|
Hi TylerLeonhardt, thank you again for reviewing this PR and enabling auto-merge! It looks like the workflows are still waiting for maintainer approval after the latest update. When you have a chance, could you please approve them to run? Thanks so much for your help! |
When persisted secret decryption fails, BaseSecretStorageService currently queues delete(key) without awaiting it before get() resolves. Because get() and delete() share the same per-key sequencer, callers can observe get() completing before the stale encrypted value has been removed.
This changes the failure path to remove the stored value directly within the current sequencer task, using the same storage-scope selection as delete(). The existing delete() path now shares that helper.
A regression test verifies that after a decryption failure the stale value is removed before get() resolves, and a subsequent get() no longer calls decrypt.
Validation: