-1 for adding this for to the API but +1 for extracting our code into a node-module. @joaomoreno how feasible is that? how much code do we add on top of other node-modules?

It's thin.

I leaving it with you then ;-)

A node package sounds like a cool solution. Let me know when it's ready so I can test it and provide feedback.

We're going with a different proxy solution in the future, skipping this.

Do you have any details about that future solution?

Actually, I might've closed this too eagerly.

We're going with using Chrome's network stack for everything. So you're a bit busted. The only way out is exposing an API for making network requests. I'll leave this open for that.

@joaomoreno any news from April ?
times to times, We have to set our password in clear so far in the settings json file in order to update OmniSharp

This is insane and quite critical
Everybody tries to point someone else team and it really hurt lots of people using VsCode in companies

Do i need to ping more contributor to VsCode in order to get more feedback on it ?

I had a progress with this which I believe may be related: after launching "code --verbose" I could see errors like the following:

ERROR:cert_verify_proc_nss.cc(969)] CERT_PKIXVerifyCert for update.code.visualstudio.com

I then followed the instructions at Linux Cert Management in order to add our corporate CA certificate as follows:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ybs -i $CA_CERT

After relaunching VSCode everything seems working!

For those visiting this from a search engine, to make extensions like C# work via an https proxy with authentication, right now you need the following:

1. You need your proxy with username and password in settings.json: "http.proxy": "https://user:pwd@host:port" (without it you will get error 407)
2. You need to install win-ca extension from ukoloff
3. You need "win-ca": "append" in settings.json (without it you will get "Error: self signed certificate in certificate chain")
4. Don't put anything else proxy or http-related in settings.json

I tested this both in 1.46.1 and 1.48.0 (with auth.js fix)

This look like it would be more sustainable to have all of this baked within VsCode, and not at the full charge of extensions developer, and at the cost of consumer security.

Somehow, having an API in VsCode return an HttpClient already setup, and supporting POSSIBLE NTLMv2 / Kerberos look like something acheivable in order to use VsCode safetly.

The equivalent in C# would look like:

public HttpClient GetMeSomethingReady()
{
  var proxyHttpClientHandler = new HttpClientHandler()
  {
    Proxy = new WebProxy("http://FROM_THE_SETTING_NO_CREDENTIALS")
    {
      Credentials = CredentialCache.DefaultNetworkCredentials
    },
    SslProtocols = SslProtocols.Tls13 | SslProtocols.Tls12 | SslProtocols.Tls11 | SslProtocols.Tls,
    UseProxy = true
  };

  return new HttpClient(proxyHttpClientHandler);

then extensions developers would do something like

var httpClient = GetMeSomethingReady();
httpClient.Get(url)

If they want to do everything from scratch ... why not, but it look like this should be

• out of the box
• 0 extensions required
• no password nowhere, as the user is already logged, and already has NTLMv2 / Kerberos ticket
• use the User Certificate Store on windows build (that's the standard)
• No env var as this would require special script to run VS not to polute shell session or user session

@orthoxerox Part of win-ca is already built-in, you shouldn't need to install it separately.

@chrmarti I shouldn't, but I had to. "http.systemCertificates": true is the default setting, but it only allows VSCode to download extensions without complaining about self-signed certs, not the extensions to download their dependencies.

Here is a workaround that enables extensions to be used in a devcontainer while a mitm solution (such as zscaler) is deployed to your network.

In devcontainer.json:

"remoteEnv": {
    "NODE_EXTRA_CA_CERTS": "<PROVIDE_YOUR_TRUSTED_ROOT_CA_CERT_HERE>.crt"
},
"postCreateCommand": "sed -i -e 's/this\\.strictSSL=/this\\.strictSSL=false\\&\\&/g' $(find ~ -name *HostAgent.js)",

I think root cause is that remoteExtensionHostAgent.js ignores all the existing settings.json files and overrides local container's npm/node configuration by default. Another way to achieve this is to configure http.proxyStringSSL in your local settings.json and then drop that into every subdirectory of the extension runtime find ~ -type d | xargs -I {} cp .vscode/settings.json {}. If anyone knows which specific folder's settings.json is used by remoteExtensionHostAgent.js, that would be a better option than using sed to edit the minified js.

Workaround for vscode.github-authentication giving a HTTP error 407 when receiving the authentication token from a browser:

In VSCode Settings, you can set http.proxy to http://username:PASSWORD@your-proxy-ip:port (or https if required) before authenticating
AND REMOVE IT once you verify your username appears in the Accounts button on the Activity Bar.
Plugins like GitLens and Settings Sync don't need to use the proxy once you've done this.

In VSCode Settings, you can set http.proxy to http://username:PASSWORD@your-proxy-ip:port

Extension proxy support #12588

One alternative to the suggestion of creating a VSCode fetch API for extensions would be to use the VSCode host as a proxy. VS Code already supports PAC files and NTLM/GSS corporate proxy authentication. Using this networking stack it could expose a port to the extensions like CNTLM. This could be exposed in the form of http_proxy env variables (so no change would be required there). Network requests would then pass through VS Code.

This feels like the simplest approach as it requires no change to extensions (continue to use http_proxy), the code for port forwarding is already in present.