- Don't set a config option for update interval. We don't let the one
in core be configurable, don't see a huge need for this.
- Don't start the server when the update is available
- Fix some race conditions
- Fix some clippy lints on Rust 1.81
I made a change this past iteration to use `CREATE_BREAKAWAY_FROM_JOB`
in order to allow the code-server process to outlive SSH connections run
from the exec server.
However, it appears that this _can_ break things if it's run from a job
that doesn't have the JOB_OBJECT_LIMIT_BREAKAWAY_OK flag set. I'm not
a winapi expert, so this is a simple though perhaps inefficient change
to probe whether we can do this via an echo command before starting the
server.
* cli: explicitly deny anonymous control port access
Prevents inheriting any ACL set at the tunnel level which may allow different access for forwarded ports
* testing: make ui more clear for discovery errors (#197115)
* testing: make ui more clear for discovery errors
Fixes#196546
* undo
* fix tests
From a refactor last literation. I don't think this is candidate worthy
as it's an uncommon path with remote-tunnels, and we can just toggle
this off for remote-ssh for this iteration.
Works quite similarly to vscode.dev. The client has a key stored in
secret storage. The server has a key stored server-side, and issues
an http-only cookie to the client. The client can ask the server to
combine its key and the http-only cookie key to a key component, which
it combines with its local key to encrypt and decrypt data.
This logic kicks in if the web server bits see a `vscode-secret-key-path`
cookie set when it loads.
Fixes#191501
It turns out this was a difference in inflate/deflate implementations
between the extension/SDK and the CLI. The SDK uses Node's zlib bindings,
while by default Rust's flate2 library uses a rust port of [miniz][1].
The 'logic' in the CLI was good, but miniz does not appear to flush
decompressed data as nicely on SYNC'd boundaries as zlib does, which
caused data to 'stall'. Telling the flate2 crate to use the native
bindings fixed this.
This could also be the cause of the flakiness occasionally seen on idle
tunnel connections!
[1]: https://github.com/richgel999/miniz
Closes https://github.com/microsoft/vscode/issues/168492
This implements @aeschli's 'server server' concept in a new
`code serve-web` command.
Command line args are similar to the standalone web server. The first
time a user hits that page, the latest version of the VS Code web server
will be downloaded and run. Thanks to Martin's previous PRs, all
resources the page requests are prefixed with `/<quality-<commit>`.
The latest release version is cached, but when the page is loaded again
and there's a new release, a the new server version will be downloaded
and started up.
Behind the scenes the servers all listen on named pipes/sockets and the
CLI acts as a proxy server to those sockets. Servers without connections
for an hour will be shut down automatically.
- Remove the `prepare` script entirely
- Variables are now populated from the product.json during build. Most
variables are mapped automatically, with some special handling in a
few cases. `build.rs` is now much more self-contained.
- Look for the `product.overrides.json` for vscode developers instead of
looking for a peer `vscode-distro` folder
Fixes#178691
* forwarding: add built-in tunnel forwarding extension
- Support public/private ports, which accounts for most of the work in
the CLI. Previously ports were only privat.
- Make the extension built-in. Ported from the remote-containers
extension with some tweaks for privacy and durability.
- This also removes the opt-in flag, by not reimplementing it 😛
Fixes https://github.com/microsoft/vscode/issues/189677
Fixes https://github.com/microsoft/vscode/issues/189678
* fixup! comments
---------
Co-authored-by: Raymond Zhao <7199958+rzhao271@users.noreply.github.com>
