Okay, so I built code-server from sources on both Linux (x64) and MacOS (arm) to identify the issue and discovered something peculiar:

Linux is explicitly excluded from signature verification, which is why the issue won't occur on Linux:

[...]
if (
	verificationStatus !== ExtensionSignatureVerificationCode.Success
	&& !(verificationStatus === ExtensionSignatureVerificationCode.NotSigned && !shouldRequireSignature)
	&& verifySignature
	&& this.environmentService.isBuilt
	&& !(isLinux && this.productService.quality === 'stable')
) {
[...]

https://github.com/microsoft/vscode/blob/17baf841131aa23349f217ca7c570c76ee87b957/src/vs/platform/extensionManagement/node/extensionManagementService.ts#L344

Meanwhile, in main line has the Linux exclusion removed. This is as of microsoft/vscode#243358. It's unclear if that will make it fail or work on all platforms.

https://github.com/microsoft/vscode/blob/main/src/vs/platform/extensionManagement/node/extensionManagementService.ts#L344

I remember seeing that Open VSX implemented some kind of signature verification, but it was never clear to me how that actually worked. I wonder if it needs to be updated?

In any case, maybe we will have to disable signature verification in the next release. I think VSCodium does that.

Disabling it for extensions downloaded from OpenVSX does make sense. It's been effectively disabled for Linux all along.

Seems like Signature Verification stalled because MSFT is keeping their tool closed off: eclipse/openvsx#543

If there is no Signer in OpenVSX and it's not just a checksum, disabling it is a loop and won't negatively affect any security properties. I favor turning it off if it makes MacOS extension installs work again for code-server and potentially avoids breakage across all platforms in upcoming releases due to VS Code's upstream change.

Ahhhhh so it might work if we make code-server use their node-ovsx-sign package.

But yeah, disabling maintains the status quo and is easier so we can do that for now.

Ahhhhh so it might work if we make code-server use their node-ovsx-sign package.

Not quite. The OSS is just a wrapper around a proprietary package/binary: eclipse/openvsx#543 (comment). The convo is> 2 years old, so I'd take that with a grain of salt.

But yeah, disabling maintains the status quo and is easier so we can do that for now.

Disabling would improve the situation because installations on non-Linux fail signature verifications. But yeah, for what's working now there will be no difference.

The OSS is just a wrapper around a proprietary package/binary

Oh wait really? The readme suggests it is an alternative to the proprietary package: https://github.com/filiptronicek/node-ovsx-sign

Disabling would improve the situation because installations on non-Linux fail signature verifications. But yeah, for what's working now there will be no difference.

Oh yup you are right; I meant the status quo before installations started failing 😆

The OSS is just a wrapper around a proprietary package/binary

Oh wait really? The readme suggests it is an alternative to the proprietary package: https://github.com/filiptronicek/node-ovsx-sign

I think the person who created the "open source clone" was equally confused: eclipse/openvsx#543 (comment)

Btw, node-ovsx-sign is outdated and the real signing happens inside of a binary that's closed source with a MSFT license:

npm install @vscode/vsce-sign

up to date, audited 3 packages in 279ms

found 0 vulnerabilities
❯ cd node_modules/@vscode/vsce-sign
❯ tree .
.
├── CODE_OF_CONDUCT.md
├── LICENSE.txt
├── README.md
├── SUPPORT.md
├── bin
│   └── vsce-sign
├── package.json
└── src
    ├── main.d.ts
    ├── main.js
    ├── permissions.js
    ├── postinstall.js
    └── target.js

3 directories, 11 files
❯ cat package.json
{
  "name": "@vscode/vsce-sign",
  "description": "Visual Studio Code extension package signing and verification module",
  "version": "2.0.5",
  "author": {
    "name": "Microsoft"
  },
  "license": "SEE LICENSE IN LICENSE.txt",
  "devDependencies": {
    "mocha": "^10.0.0"
  },
  "optionalDependencies": {
    "@vscode/vsce-sign-darwin-arm64": "2.0.2",
    "@vscode/vsce-sign-darwin-x64": "2.0.2",
    "@vscode/vsce-sign-win32-arm64": "2.0.2",
    "@vscode/vsce-sign-win32-x64": "2.0.2",
    "@vscode/vsce-sign-linux-arm64": "2.0.2",
    "@vscode/vsce-sign-linux-arm": "2.0.2",
    "@vscode/vsce-sign-linux-x64": "2.0.2",
    "@vscode/vsce-sign-alpine-arm64": "2.0.2",
    "@vscode/vsce-sign-alpine-x64": "2.0.2"
  },
  "homepage": "https://github.com/Microsoft/node-vsce-sign",
  "main": "src/main.js",
  "scripts": {
    "postinstall": "node ./src/postinstall.js",
    "package": "node ./build/package.js",
    "download": "node ./build/download.js",
    "test": "mocha ./src/test/*.test.js --timeout 5s --fail-zero --exit"
  }
}

I did read eclipse/openvsx#543 (comment), but it does not make any mention of node-ovsx-sign; did you mean to link a different comment? That comment says that VS Code uses the proprietary node-vsce-sign package and links to the place in the open source code of VS Code where that happens.

As for node-ovsx-sign, it does not appear to have @vscode/vsce-sign nor node-vsce-sign as a dependency (nor could it, since that package does not appear to be publicly available anywhere), and if you look at the source you can see it uses native crypto for both signing and verification after downloading the public key from the marketplace with no imports or mention of vsce-sign.

Btw, node-ovsx-sign is outdated

What makes you say node-ovsx-sign is outdated? It seems to just use native crypto.sign and crypto.verify and download the public key, so it may just be simple enough not to need very much maintenance. Or did you mean node-vsce-sign is outdated? It looks like Microsoft renamed node-vsce-sign to @vscode/vsce-sign.

the real signing happens inside of a binary that's closed source with a MSFT license:

True that Microsoft builds of VS Code bundle and use the proprietary @vscode/vsce-sign package, but in OSS builds of VS Code like code-server neither @vscode/vsce-sign nor the older node-vsce-sign package has ever been available, and from what I can tell we could use node-ovsx-sign as a replacement in code-server, if we did want to make signing work.

But...that is just for OSS builds like code-server. I guess this means it is impossible to support Open VSX or any other marketplace on the official Microsoft build of VS Code unless users disable signature verification...

Very interesting announcement here about private marketplaces though: microsoft/vscode#21839 (comment)

@code-asher, the switch to the "new" NPM module happened here: https://github.com/microsoft/vscode/pull/205511/files. It might just be a rename 🤷.

My whole point was that two years have passed since eclipse/openvsx#543 (comment), including the recent comments, and the information is likely stale according to my prior point that now the module has even a different name/source.

The private marketplace announcement is interesting. All tech obstacles aside, MSFT's licensing on the marketplace and extensions distributed through it are a legal blocker. Maybe this announcement will move the needle on that front.

Yeah, that makes sense, I think they have been moving all their modules under the @vscode namespace.

My point is the opposite, that as far as I can tell, the closed-source module still works the same despite the rename, so I see no blockers to dropping in the open-source node-ovsx-sign as a replacement to the closed-source @vscode/vsce-sign/node-vsce-sign if we need to implement signatures.

Not sure how many users care about signatures though...part of me wonders if this is just a move by Microsoft to ensure 3rd party builds are not using the marketplace. 😛

Maybe this announcement will move the needle on that front

Exactly my hopes!

Yeah, that makes sense, I think they have been moving all their modules under the @vscode namespace.

My point is the opposite, that as far as I can tell, the closed-source module still works the same despite the rename, so I see no blockers to dropping in the open-source node-ovsx-sign as a replacement to the closed-source @vscode/vsce-sign/node-vsce-sign if we need to implement signatures.

I'm with you. I do want you to be correct. 👍

In the short term, I'm looking forward to getting extension installs unblocked on non-Linux platforms.