Extension Publisher Signing

[isidorn]

Marketplace is finishing their work on extension repository signing. To summarise, all extensions on upload will get signed by the Marketplace. Upon download of an extension VS Code will verify this repository signature. Using this approach we can be certain that the package that VS Code downloaded is indeed the one that got uploaded to the Marketplace. More details about the repository signing will be announced in November when this feature will most likely launch 🚀

In the meantime I wanted to discuss another topic - publisher signing. This is a feature that the Marketplace team is starting to think about and it would allow extension authors to directly sign their extensions. VS Code would verify this signature to make sure that the extension bits indeed came from the respective author. Publisher signing is not to be confused with repository signing and these two are independent security features that verify different parts of the supply chain.

Publisher signing has a lot of benefits, but my personal favourite is the ability for extension authors to specify that only extensions that are signed with a specific certificate should be accepted by the Marketplace. Using this, even if an extension author's Marketplace account is compromised by a malicious actor, that actor would not be able to upload any new extensions (or update existing ones) since those extensions would not be signed 🔒

Some questions that I have:

• Imagine that Publisher Signing was available today - would you start publisher signing your own extensions?
• How do you imagine the signing process would look like? Would you expect to sign from a pipeline using a cli tool like vsce?
• If Publisher Signing would require extension authors to have their own trusted certificate (usually costs around 100$ per year with DigiCert). Would this be a deal breaker?
• Are there other signing solutions that you are using in your other projects that you find particularly appealing? Why did you choose these signing solutions?

Let me know what you think and if you have any other questions. We are looking for any feedback that might help us in how we design the extension publisher signing experience since we are still in the very early phase. Thanks 🙏

[worksofliam]

How do you imagine the signing process would look like? Would you expect to sign from a pipeline using a cli tool like vsce?

Yes, vsce with something like --sign would be the only way to sign I'd think. If I can't sign through a pipeline, then I'd be kind of put off. Please consider keeping the signing process easy in regards to pipelines.

If Publisher Signing would require extension authors to have their own trusted certificate (usually costs around 100$ per year with DigiCert). Would this be a deal breaker?

Would you plan on not allowing unsigned extensions? This might improve the quality of extensions on the Marketplace if that were the case. Also, I assume I can use the same cert for many extensions in my business?

My concern is how we obtain that certificate and where we store it. It needs to be simple to obtain and sign my extension during publish in a pipeline.

[isidorn]

Yes, our goal is to make the signing process easy in regard to pipelines.

Would you plan on not allowing unsigned extensions? This might improve the quality of extensions on the Marketplace if that were the case. Also, I assume I can use the same cert for many extensions in my business?

Currently we have no plans to allow only signed extensions on the Marketplace. We envision that this should be controlled by the extension author, so each extension author can specify that all their extensions have to be publisher signed. And yes, using the same cert for many extensions is fine.

My concern is how we obtain that certificate and where we store it.

This is something which we are thinking about. I agree we should make this as simple as possible.

[claui]

@isidorn I’d appreciate if publishers had a way to sign their extensions.

Would it make sense to support PGP for that? Some developers are already using it to sign their commits.

For example: microsoft/vscode@release/1.71...release/1.72
(GitHub shows a Verified badge next to signed commits.)

[isidorn]

Thanks for the feedback. This is something we have discussed and we are not sure if we will go down this route. We are exploring multiple options and we will know more in the next couple of milestones.

[GitMensch]

Using PGP has at least the benefits of:

• ease of use and integration into pipeline, works multi-platform
• available without cost for the author
• the extension author could setup the public key(s) in the marketplace after login, then those would also be shown there
• can be verified "offline" by users, too

The only downside:

• if marketplace account is compromised and the keys can be changed there, this attack scenario would not be solved - could be independently by two-factor authentication or simillar

[wkillerud]

For context: I'm not too familiar with signing, the current state of the art for tools, or average cost for these things elsewhere.

• Imagine that Publisher Signing was available today - would you start publisher signing your own extensions?

Probably, yes. I would expect the demand to be there from extension users after a while.

• How do you imagine the signing process would look like? Would you expect to sign from a pipeline using a cli tool like vsce?

I would probably expect it to be either a flag for vsce package or a separate command, but definitely a tool in vsce to ease the process. I'd be willing to set up and use something more complex if there was a guide tailored for VS Code extension authors.

• If Publisher Signing would require extension authors to have their own trusted certificate (usually costs around 100$ per year with DigiCert). Would this be a deal breaker?

Absolutely a dealbreaker, unless there is a clear value provided to the one paying the bill. I could be persuaded if:

• There are tips for maximising the value of the certificate ("A trusted certificate can also be used for x, y, and z – you will get so much use for this thing!").
• The cost was an order of magnitude lower. Preferably free of charge, provided by Marketplace, since signing increases security and perceived quality of your platform.

Currently we have no plans to allow only signed extensions on the Marketplace.

Good, and as long as there would be such a cost involved in signing it should stay that way. I build my extension in my spare time and provide it for free, so I already feel like I pay enough in that sense.

I get that there's an infrastructure/platform cost involved from your perspective, but if the price of admission was 100$ I would stop publishing on Marketplace in a heartbeat.

• Are there other signing solutions that you are using in your other projects that you find particularly appealing? Why did you choose these signing solutions?

I don't know if it's relevant, but I'm interested in SSH commit verification. (When I checked back in August, my Git version on macOS didn't support it yet.) SSH keys is something I'm familiar with, and it looks fairly simple to configure Git and GitHub to use SSH keys for signing.

[isidorn]

Great feedback, thanks a lot! We are definitely taking all of this into account.

[PEZ]

but if the price of admission was 100$

While I agree that this would be expensive, I do not read the question as if Microsoft would be charging this fee. It is more about that someone needs to provide the verification that I am who I say I am, or the signature has little/no value. This kind of service has a market price today, which I guess is what is for reasons.

Just wanted to add this note to calibrate that I have understood things correctly with @isidorn . I am not very savvy with signing...

[isidorn]

Correct. This would not be charged by Microsoft but by a third party company to verify identity.
We are not leaning towards going down this route, and we will try to deliver a publisher signing solution that is free. We will have more details in the next couple of months. Thanks!

[ssbarnea]

Introduction of signing based on SSL certificates has the potential of ruining the entire extension marketplace, which is mostly based on one-person backed extensions. Current maintainers will have no time to procure, setup and maintain a certificate.

Signing should be made in a way that is extremely easy and free to use regardless if you are a corporation or a single-person open source enthusiast.

[GitMensch]

Correct. [...] we will try to deliver a publisher signing solution that is free. We will have more details in the next couple of months. Thanks!

If MS would finally provide a code-signing certificates (at least for "open-source developers signing open-source" that would not require paid third-party solutions, that would indeed be a step forward.

[wkillerud]

Are there other signing solutions that you are using in your other projects that you find particularly appealing? Why did you choose these signing solutions?

I was introduced to Sigstore today for code signing via Trail of Bits. On first glance it seems like it could be relevant (and promising!).

From "How do I use sigstore?":

To get started, we’ll install sigstore-python, the official (and Trail of Bits maintained!) Python implementation of Sigstore:

$ python -m pip install sigstore

Once we have it installed, we can use it to sign a local file (you can sign anything, including Python packages or distributions for any language!):

$ python -m sigstore sign README.md
Waiting for browser interaction...
Using ephemeral certificate:
-----BEGIN CERTIFICATE-----
(omitted for brevity)
-----END CERTIFICATE-----
Transparency log entry created at index: 6052228
Signature written to file README.md.sig
Certificate written to file README.md.crt

This just works™

[ShamrockLee]

Marketplace is finishing their work on extension repository signing. To summarise, all extensions on upload will get signed by the Marketplace. Upon download of an extension VS Code will verify this repository signature.

That would be great!

As a user and contributer of Nixpkgs, I would be concerned whether the verifying API/key would be publicly available or not.

In Nixpkgs, users can specify the set of extensions they would like to use in a domain-specific language called "Nix expression", and reproduce an identical environment on another computer. To ensure reproducibility, the build system downloads the extension, verify it with the given checksum (which is usually SHA256), unpack it, place the files under specific directory hirarchies (with some hashed directory names) and make it visible to the VSCode binary.

If the signature-verification key/process is not publicly available (or even be viewed as a trading secret), I wonder if we could continue to enjoy the rich features of VSCode together with the reproducibility of Nix. Or, if the verification happens only during the download, the build could still work without the benefit introduced in this change.

It would be another plus to have a way to fetch the checksum (SHA256 or SHA512) of the VSIX file without downloading the VSIX file itself. We would be able to automate the build process without manually fetching the hashes then.

[GitMensch]

Providing public hashes in the marketplace under "versions" would be definitely an easy thing to implement and quite beneficial; providing an API to directly query the hash of a given extension would be quite useful for automated builds, please consider that!

[ShamrockLee]

The current extension query / download API (extension gallery) is left undocumented (at least not publicly available). The only "documentation" available is the source code of VSCode-OSS.

[VorpalBlade]

If Publisher Signing would require extension authors to have their own trusted certificate (usually costs around 100$ per year with DigiCert). Would this be a deal breaker?

Some reasons against it:

• This would be quite difficult or impossible for smaller, niche, open source extensions to justify.
• The world as a whole is moving in the opposite direction: Let's Encrypt democratised server certificates. I don't know what the state of this is for code signing. But isn't it better that everyone can sign their code and get security than only those who can afford to pay?

I would suggest that a better approach would be something like how SSH keys are commonly handled on platforms like GitHub etc: Allow you to specify which ones are valid via a web UI. The web UI should probably require re-authentication with 2FA when you try to change things and monitor for suspicious logins (unexpected country etc).

There are other ways to secure it even more (while not incurring unreasonable costs for small developers/hobbyists): For example: require that any new key is signed with the previous key (and require that the developer sets up a "current" and a "backup" key from the beginning).

[isidorn]

Thanks for your comment. Same as I answered another comment - we acknowledge that without a free solution this feature would most likely not be successful. Thus, we are currently investing into a free signing solution, and once we have a proposal I will share more in this discussion.

As for your suggestion - thank you for sharing that.

[jlynchMicron]

Is it possible that this update would break REMOTE extension installs if it is not using the application proxy setting? After this update, none of my extensions are installing with error messages like this:

[error] Untrusted: Signature: Untrusted
[error] Signature: Untrusted

I think it would be related to this issue:
microsoft/vscode-remote-release#986

If this is the case, can we disable extension signature verification? Or could the remote session fallback to installing from the up-to-date extension residing on the host version of VScode?

[isidorn]

This looks like an unrelated error. Though it would be great if you can open a new issue here https://github.com/microsoft/vscode/issues

[dtivel]

@jlynchMicron, can you please open an issue with an example extension that fails for you as well as information about the platform on which you're trying to install (e.g.: Windows 11, Ubuntu 22.04, etc.)? Please tag me on the issue.

[jlynchMicron]

Issue made, thanks!
microsoft/vscode#173327

[pgwatinfor]

Until publisher signing is available and Marketplace signs our extension.
What will happen in the following scenario:

The extension is installed from Marketplace into VS Code.
Is it still possible to install an unsigned VSIX file of the same extension from command line

code --install-extension myextension.vsix

or will this be blocked in some way?

[isidorn]

Good question. This is currently possible and will not be blocked. However this flow will currently not verify a signature. We are still discussing this flow and if it should fetch the signature from the Marketplace and verify the extension if it can.

[synesthesia]

Whilst understanding the importance of signing extensions for peace of mind for all of us, the cost of a developer signing certificate would be an absolute deal breaker as far as I was concerned.

[isidorn]

Thanks for sharing. We acknowledge that without a free solution this feature would most likely not be successful. Thus, we are currently investing into a free signing solution, and once we have a proposal I will share more in this discussion.

[webdevnerdstuff]

Will this also be the same when it comes to themes (possible fee)? In theory they are not a traditional extension, and technically only json files. Having to pay a cost for that would definitely be a deal breaker for me as that is the only thing that I use vsce with to publish. I don't use it to generate any income so it would wind up costing me money just to share something I made available to others as more of a way to share in the same way that I share open source Plugins, Components, etc. on my GitHub/npm accounts.

[isidorn]

Same as my comment from above - we are working on coming up with a free solution.

[kkm000]

Publisher signing has a lot of benefits

This is a blanket statement. Any secure system design starts with exquisitely specific attack scenarios.

my personal favourite is the ability for extension authors to specify that only extensions that are signed with a specific certificate should be accepted by the Marketplace.

1. This has nothing to do with a certificate. Signing per se implies only a signing key. The original intent of the certificate was to legally certify facts about its owner. This intent is now extant only in the so-called “extended validity” (EV) certificates.
2. Scenario: the user's signing key is compromised, but their account is intact. How is the signing key revoked without losing the account?
3. The industry-standard method of protecting an account is MFA. I do not cryptographically sign pictures before uploading them to my Google Photos to prove that it's really me. Instead, I protect access to my whole Google account with a second factor. I fail to see why anything at all needs to be reinvented here.

Imagine that Publisher Signing was available today - would you start publisher signing your own extensions?

This depends on a multitude of factors. Blanket question, blanket answer: depends on how cumbersome the process is.

Would you expect to sign from a pipeline using a cli tool like vsce?

With a derived key, yes. With the master key, unacceptable risk. Commonly, the master signing key is released only upon confirming physical presence of the owner (e.g., tap a button on the YubiKey).

If Publisher Signing would require extension authors to have their own trusted certificate (usually costs around 100$ per year with DigiCert). Would this be a deal breaker?

Yes, indeed, it would put the Marketplace out of reach of anyone but major commercial software publishers.

1. Your price figure is off by a factor of more than 5. Guess which way. Even $100 is as far as it goes from a pocket charge for the majority of the world outside of the US, UK, Japan, Taiwan and a few Western European countries. At the very least, this would be too high a bar for developers from India and mainland China. So, the majority of the world's software engineers. Even at $20/year, it still would.

2. The non-EV certificate issued by DigiCert certifies two facts: that the key's owner has (a) paid DigiCert $539 (US) for enjoying a whole year of the fairly questionable pleasure of being able to sign software, and (b) honestly provided the real X.509 dName. The DN CN=Jesus Christ,L=God Butte,S=Oregon,C=US qualifies (it's easy to confirm that the L(ocality) God Butte is in fact in the S(tate) of Oregon, C(ountry) US; but whether or not Mr. Christ is in fact resident of this locality is significantly harder to validate). Please do not support this racket.

   On a tangent, the concept of an X.509 certificate is extremely antiquated, and survives in endpoint authentication capacity only because it has ossified in Internet standards that are here to stay for a long while. More so, it was initially specified for both authentication and transport security, which was indeed a mistake; in fact, alternative PFS KEX schemes (curiously, the first KEX algorithm has been published by Diffle and Hellman in 1979, and pre-dates even RSA) have been long used for securing the channel. Alternative authentication schemes have also been in use for a while; e.g., the non-profit LetsEncrypt, which mechanically issues short-living X.509 domain authentication certificates free of charge by confirming either domain ownership via an encrypted token in the domain's TEXT record, or successful server name DNS resolution, as a security protocol.

   Besides, the identity of a private person software publisher in the context of their possible publishing of malicious VSCode extension, even if in fact established by a trusted third party, matters little: a legal action against such an actor is invariably costly and net-negative. A major malware operator, on the other hand, will have no trouble obtaining a non-EV certificate, even if the issuer verifies the credit card: obtaining a stolen CC is a piece of cake for them.

3. The EV certificate, a real one, by issuing which DigiCert in fact legally certifies the identity and address-on-record of the business, is out of reach of a private person, requires registering a business, and costs a small fortune.

Are there other signing solutions that you are using in your other projects that you find particularly appealing?

I am not developing signing solutions, but I use them. Here are two that might be of interest.

1. Debian packages. The distribution includes software with unlimited privileges, such as kernel modules. Unlike the most projects around Linux kernel, including the kernel itself, Debian is not sponsored by any business, and is one of a few projects ran entirely by volunteers. Naturally, this precludes throwing money at DigiCert for the sake of throwing money at Digicert. Both distribution points (repositories) and packages themselves are signed; this signature is separate from transport security. Here is a short summary and the full description of various WNPP procedures in the Debian ecosystem (proposing own software, requesting existing software, adopting orphaned packages, etc.) The system is based on a reasonable mutual trust in the development community. Despite this apparently low level root-of-trust, Debian has been a major platform in the server segment, and will probably replace the void left by the discontinuance of CentOS by RedHat.

   The distribution model permits own distribution points (PPA). Basically, as a user, you add the public key of a PPA if you trust it. The packages distributed via a PPA, obviously, are verified for integrity only, and have the same trust level as that which the user assigns to the PPA as a whole.

2. WebExtensions. This model is closer to VSCode extensions: they are amenable to automatic verification of their manifest (i.e., that the extension in facts adds such and such commands etc). Here's the publishing process documentation. I never published an extension, but I repackaged and signed a multilingual spell-checking dictionary for my own use without any issues when Firefox ceased installing unsigned extensions.

Finally, the value of attaching certified identity to extensions is greatly diminished by

the security features that are really, sorely missing

Unlike browser extension or Android apps, VSCode extensions have full access to the user's system, without any granularity. Reducing the attack surface is the most significant security measure by any textbook. I would even hazard to say that ensuring integrity/identity of extensions has a far lower priority than compartmentalizing extension's access to the core API. Security risks from a malicious or simply malfunctioning extension that is only supposed to display the currently selected profile in the status bar (ahem, hint, hint: maybe we don't need a whole extension for that?) and another, which deploys a debugger proxy executable, should be different. As is with WebExtensions, the manifest should declare the subset of API it will be given access to, at a sensibly granular level, and this subset should be visible to the installing user, translated into natural language.

Simply, I would be much more comfortable installing a totally unsigned extension that is given manifest permissions to create a sidebar, access editor's buffer read-only and augment semantic information than an extension that is, as it currently stands, is given full filesystem access, including remote, but provably signed by Joe Bloggs, of whom I've never heard, of course. As you perfectly know, extensions on the Marketplace can be subdivided into 4 major categories: (a) made by Microsoft, (b) published by developers of a simple, single-function extension, which they likely made for their own convenience, (c) expensive, often with free crippled demo versions and (d) 1% outside of the first three kinds.

Are you absolutely sure that your priorities are set optimally?

[meadowsys]

Very excellent writeup, feel compelled to leave a comment letting you know that I have read and appreciated it c:

[Simonl9l]

as per the comment above..seems that with sigstore there is a zero cost to extension developers - it just requires an OpenID Connect authentication, that should be achievable for most - perhaps even via GitHub as an IdP?

Not sure why no one replied to @wkillerud 's contribution but were so carful to reply to others.

There are also other issues tied to this conversation.

[GitMensch]

Even sigstore needs a more complex setup (feel free to link to a "from start to your first signed artifact in N steps" doc; that would really be useful), and with OpenID Connect it only guarantees that you have a mail somewhere and have access to that, possibly with a two-factor (so the "valid" keys still have to be managed somewhere outside.

GPG keys provide the same level as long as the marketplace and the client (like vscode) uses both the system-available list and a list of "know public good and unrevoked" keys that a maintainer could upload. And both the signing and the validation works both locally and in CI.