vscode: Extension installation fails to verify signature on REMOTE release

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

  • VS Code Version: 1.75.0
  • OS Version: CentOS Version 7

Steps to Reproduce:

  1. Open up new VScode remote session.
  2. Try to update any extension.

Tagging maintainer per request: @dtivel

Important note: Using identical corporate proxy settings for both environments, which worked before latest VScode update 1.75.

Windows 11 Host (extensions install fine): image

Linux Remote SSH Session (extensions not installing, note the python extension): image

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 5
  • Comments: 39 (14 by maintainers)

Most upvoted comments

@sandy081

  1. That’s not a valid setting
  2. It doesn’t work

@shaoqx Facing the same problem here on the remote server. I found it first with my home laptop and again with my working PC once I updated VSCode on the PC to 1.75.0. Tried the 2nd fix with extensions.verifySignature. It only works after I killed the current Code server with Remote-SSH: Kill Current VS Code Server

Proofed (Rocky Linux 9.0), and works well. thanks for the information.

If Already Upgrade to 1.75

  1. Update the remote settings to use extensions.verifySignature and set it to false
  2. Killed the current Code server with Remote-SSH: Kill Current VS Code Server
  3. (Disconnected from Remote)
  4. Restart host VS Code
  5. Try to install extensions and make sure it works
  6. Done

I am connecting from MacOS to Linux host but none of the above fixes worked for me. I tried everything in xiaoshude’s comment which summarizes all the fixes in this thread so far but I still get an “Untrusted” error (I used the Docker extension as the example in the blow screenshot) image

@dtivel @sandy081 and me discussed this and we decided on the following: for Linux distributions (like Red Hat and CentOS) that do have this established system (root-owned) code signing trust store, we will still give priority to the trust store that is shipped with VS Code. This way we can be 100% sure that the trust store we use is valid for code signing.

This fix will be included in the next Stable release that we plan to do on Wednesday or Thursday (Feb 8th).

In our February milestone we plan to introduce a setting, for example "extensions.signatureTrustStore" "product" | "system" (default is “product”) that will allow users to control what trust store should VS Code use. In the future when VS Code introduces more settings to be admin controlled, this can be the mechanism for system admins to control what trust store is to be used.

After you get this stable update I would kindly ask all of you to remove the extensions.verifySignature: false from your settings, because we want signature verification to not be disabled and to hear if there are any other issues that we might have not fixed. Thank you very much!

Facing the same problem here on the remote server. I found it first with my home laptop and again with my working PC once I updated VSCode on the PC to 1.75.0. Tried the 2nd fix with extensions.verifySignature. It only works after I killed the current Code server with Remote-SSH: Kill Current VS Code Server

FWIW this also happens in the Dev-Containers extension workflow. I can’t install any extensions in the container and if I update the settings file, since it doesnt get picked up I have to rebuild the container, which ultimately wipes out the settings.json all over again

Downloading vscode 1.74.3 can suppress this issue.

@zulrang , worked for me after killing a server process on a target machine.

Reloading Windows, close/open VS Code did not help. Only after a “power cycling” a VS Code process server, extensions got updated.

@dtivel

Thanks for jumping on to this and inspecting the issue.

Immediate Workaround

Disable signing verification manually

  • Open Settings UI
  • Go to Remote Settings Tab
  • Open the Settings file by clicking on the button available on the top right corner
  • Add this setting "extensions.verifySignature": false
  • Please note that this setting is not available in UI. You have to open the remote settings file and update the setting manually.
image Screenshot 2023-02-04 at 18 06 45

Recovery

  • Disable signing automatically for the platforms where this can happen

Long term

  • Come up with a solution where we can verify signing successfully in these cases

@sandy081 there’s simply no such setting as “extensions.verifySignature”.

BTW, I reverted to 1.74.3 but then it turned out ALL MY REMOTE EXTENSIONS WERE GONE. What the… is happening?

@dtivel, thank you for looking into this! Yeah I don’t think my organization would let us tamper with the system root certificate.

I can go with option 2 for now, but if that option disappears in the future, I’m not sure what options we will have down the road.

The code signing certificate that VS Marketplace uses to repository sign extensions chains to this root, so trusting this root will resolve the Untrusted error you’re seeing.

To verify extensions signed with this certificate, VS Code requires a certificate trust store that is valid for code signing.

Linux doesn’t reliably have this, so VS Code defaults to using its own built-in trust store. This built-in trust store is effectively a snapshot of the Windows trust store that is valid for code signing and contains this root certificate.

For the Linux distributions (like Red Hat and CentOS) that do have this established system (root-owned) code signing trust store, we want to respect it. The intent here is to reuse a system-managed trust store if we can.

/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem

I see a few options:

  • Add the root certificate to your PEM file. This is a system-wide change, so you should be comfortable with the change.
  • Set the extensions.verifySignature option to false in the right setting file (remote, in your case). This should be considered a short-term workaround, and the option may disappear in the future.
  • Downgrade to 1.74.3.

For now, I’d choose the 2nd option.

CC @isidorn