Keytar Migration Plan

[TylerLeonhardt]

Hello :wave: I'm Tyler from the VS Code team. I'm opening this issue because you use the keytar shim that VS Code provides in the Teams Toolkit extension.

Keytar is officially archived and not being maintained... In an effort to promote good security practices by not depending on an archived piece of software for storing secrets, we are working on a plan to remove this shim from VS Code. We want to communicate this to you so we minimize the disruption due to this change, hence this issue. I know this isn't the best news... we had a fair amount of work to remove our dependency on keytar as well, but we believe this is the right thing to do to ensure extensions are using secure APIs.

There are a couple of options for you to consider:

• (recommended) Use the SecretStorage API that VS Code provides on the ExtensionContext. This API is cross-platform and will work on all platforms that VS Code supports. It is also maintained by the VS Code team and will continue to be maintained and has been a part of the VS Code API for years at this point.
• (not recommended) You can bundle the keytar module with your extension. Keep in mind that keytar is a native node module which means that you will need to publish a platform specific extension for each platform you want to support.

Timeline

The current plan is to remove this shim from VS Code Insiders in early July which means that August 2023's stable release will be the first release without the shim.

Questions?

If you have any questions, please feel free to ask them here. I will do my best to answer them as quickly as possible. Your cooperation is greatly appreciated :heart:

[ghost]

Thank you for contacting us! Any issue or feedback from you is quite important to us. We will do our best to fully respond to your issue as soon as possible. Sometimes additional investigations may be needed, we will usually get back to you within 2 days by adding comments to this issue. Please stay tuned.

[xiaolang124]

@TylerLeonhardt Thank you for bringing up the keytar migration plan. I have a question regarding this. Previously, we followed the guidance in this document (https://code.visualstudio.com/api/advanced-topics/remote-extensions#persisting-secrets) to persist secrets, and we have multiple versions available in the marketplace. If VS Code removes the keytar shim, will the older versions of Teams Toolkit still function properly, or will it cause compatibility issues?

The second question is regarding the process of migrating secrets from keytar to the SecretStorage API. Are there any plans or features in VS Code to facilitate this migration, or will we need to handle it ourselves?

[TylerLeonhardt]

Hi @xiaolang124, here are the answers to your questions:

Previously, we followed the guidance in this document

Nice find on that doc, I wasn't aware of that one and I've sent a PR to go ahead and update the guidance to use the SecretStorage API: https://github.com/microsoft/vscode-docs/pull/6423

If VS Code removes the keytar shim, will the older versions of Teams Toolkit still function properly, or will it cause compatibility issues?

I don't know how your extension works, but if it expects keytar to be present, then it will cause compatibility issues when keytar (and thus, the KeytarShim) is no longer present.

The second question is regarding the process of migrating secrets from keytar to the SecretStorage API. Are there any plans or features in VS Code to facilitate this migration, or will we need to handle it ourselves?

Unfortunately, you will need to handle this yourself because the new API does not know about how you previously called keytar.

If keytar wasn't deprecated/unmaintained, we would be able to have a longer period of transition here, but since it is, we are trying to stop folks from depending on an unmaintained piece of software to deal with sensitive data is not good.

[xiaolang124]

@TylerLeonhardt Thanks for the answers. So, in the future, will these codes return undefined? Am I correct?

try {
    return r(`${env.appRoot}/node_modules.asar/${moduleName}`);
} catch (err) {
    // Not in ASAR.
}
try {
    return r(`${env.appRoot}/node_modules/${moduleName}`);
} catch (err) {
    // Not available.
}
return undefined;

[TylerLeonhardt]

Yes that's correct. We will completely remove keytar from VS Code.

[xiaolang124]

Got it, we will update these codes in the upcoming sprint.

[xiaolang124]

@TylerLeonhardt Hello, may I ask about the release plan? Previously, you mentioned that the plan was to remove this shim from VS Code Insiders in early July. I have tried version 1.81.0-insiders, which was released on July 14th and keytar is still bundled. Could you please help to provide an update on when this change will be implemented in VS Code Insiders?

[TylerLeonhardt]

@xiaolang124 we pushed it back a month based on usage on telemetry. That said, the numbers are dwindling and we could be on track to remove it next month.

[xiaolang124]

@TylerLeonhardt Thank you for the information. Can I be more specific about the timeline? Will this change take effect in VS Code Insider in August? And will the stable release be in September? Or can you share any time plan? Also, how long will it take to ship the change from insider to stable release?

[TylerLeonhardt]

Here is the general plan that will be executed:

• First week of the month: remove all keytar references from VS Code source code
• First week of the month: release first Insiders without keytar
• First week of the following month: release first Stable without keytar

Right now, the timeline we are running with is starting this process in August. However, this can be adjusted based on what we see in telemetry. We have telemetry that picks up extensions using our keytar shim and if there is a substantial amount of usage still, then we will push it back.