coder
[Feat]: Allow installing .vsix extensions in restricted environments
What is your suggestion?
Allow users to install .vsix extensions offline via the CLI.
Why do you want this feature?
Some community members and customers work in airgapped or offline environments and want to be able to install extensions.
Are there any workarounds to get this functionality today?
No.
Are you interested in submitting a PR for this?
Yes
Related
Technically this is upstream, but I'm considering fixing it first in code-server and then submitting a patch upstream
https://github.com/microsoft/vscode/issues/142812
I believe we can already do this by running the following:
code-server --install-extension /path/to/my/extension.vsix
I've tested this without a network connection and everything works as expected.
You're right 🤔
Weird. I used --log trace and don't see anything about it trying to access the internet.
cc @code-asher can you confirm you're seeing the same thing? Maybe this is no longer an issue.
Huh yeah it works for me too now. I tried the Python extension which was the one that was hanging for me.
Hmm...this person says it's still happening. I may investigate adding an integration test to verify that it does not make any network requests and works offline.
I'm using a slightly outdated version of code-server (v4.3.0) but I run into the same issue which is that it takes a little over 2 minutes for a single extension to install. I've never had one outright fail to install, it's always just been very slow because of the call to the marketplace that's been added to VS Code sometime ago now.
@cccs-nik are you in an offline or restricted environment? @code-asher noticed that the behavior is different with the latest version.
Yeah I'm in a restricted environment. I'll give the latest version a try and get back to you.
@jsjoeio I tried with code-server v4.6.0 (Code 1.70.1) and I'm getting the same behavior still. A little over 2 minutes for a single extension to install.
@cccs-nik very helpful - thank you so much! Appreciate your help.
I was chatting with @code-asher - we believe that this only happens in restricted environments. He was doing some poking around to see if we could figure out what the root cause is. Still working on that though.
Yeah I am still unclear on how exactly to reproduce. I have tried 1) going offline and 2) blocking open-vsx.org via DNS but I think to reproduce we need DNS to resolve and then for the request not to be blocked but to not respond at all. Maybe like a firewall that just drops packets.
If there is a firewall dropping packets then I assume there is a timeout somewhere in code-server we can lower although I am not sure what a good timeout is; maybe in some slow environments it really does take two minutes to resolve. So if this is what is happening then the ideal fix is likely to make the firewall respond with a denial rather than silently dropping.
Yeah I am still unclear on how exactly to reproduce. I have tried going offline and blocking open-vsx.org via DNS but I think to reproduce we need DNS to resolve and then for the request not to be blocked but to not respond at all. Maybe like a firewall that just drops packets.
@code-asher i've ran tcpdump while starting code server and installing local VSIX extesions. found the following URL's to be requested: (i've ran this in a container to make sure nothing else is running or might interrupt the records)
DNS 238 Standard query response 0x2814 A openvsxorg.blob.core.windows.net CNAME blob.dub09prdstr08a.store.core.windows.net A 20.60.40.4
DNS 177 Standard query response 0x537d AAAA open-vsx.org SOA dns1.datacentres.rogers.com
That makes sense, those queries must be timing out in some environments. Looks like the upstream issue has stalled unfortunately.
One dumb hack that I think will work is to unset the marketplace gallery:
EXTENSIONS_GALLERY='{}' code-server --install-extension ./my-extension.vsix
Closing this out for now since it appears to be an upstream issue which while we could patch, would be better fixed upstream, and because I think this can be resolved by blocking requests immediately rather than timing them out, although admittedly I am fuzzy on how this happens.