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.
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>
This reuses a lot of the logic we use for the normal VS Code Server
tunnel to do port forwarding. It does use a _different_ tunnel than what
Remote Tunnels would otherwise use for the control server. The reason
for this is that ports exist on a tunnel instance, and if we reused the
same tunnel then a client would expect all CLI hosts to serve all
tunnels, where the port forwarding instance would not provide the VS
Code server. It also reuses the singleton logic so all ports on a
machine are handled by a single CLI instance for the same reason: we
can't have different instances hosting subsets of
ports on a single tunnel.
Currently all ports are under the default privacy: support for
public/private tunnels is either later today or next iteration.
* cli: allow exec server to listen on a port and require token authentication
For remote ssh on Windows where pipe forwarding doesn't work
* fix linux build
- Apply the name/tunnel-name from the CLI to automatically
(do a normal tag sync). Previously the CLI could host tunnels that
were unusable unless the consumer did the tag setup, which they
should not.
- Allow "tunnel ID" to be specified in the new `<id>.<cluster>` format
that devtunnels has adopted.
- When turning on remote tunnel access, a quickpick is now shown asking
users whether it should be installed as a service or just run in
the session.
- Picking the service install will install the tunnel as a service on
the machine, and start it.
- Turning off remote tunnel access will uninstall the service only if
we were the ones to install it.
- This involved some refactoring to add extra state to the RemoteTunnelService.
There's now a "mode" that includes the previous "session" and reflects
the desired end state.
- I also did a cleanup with a `StreamSplitter` to ensure output of the
CLI gets read line-by-line. This was depended upon by the remote tunnel
service code, but it's not actually guaranteed.
- Changes in the CLI: allow setting the tunnel name while installing the
service, and make both service un/installation and renames idempotent.
Closes https://github.com/microsoft/vscode/issues/184663
* signing: implement signing service on the web
* wip
* cli: implement stdio service
This is used to implement the exec server for WSL. Guarded behind a signed handshake.
* update distro
* rm debug
* address pr comments
Other connected clients will now print:
```
Connected to an existing tunnel process running on this machine. You can press:
- Ctrl+C to detach
- "x" to stop the tunnel and exit
- "r" to restart the tunnel
```
These are then sent to the server to have that take effect. This is
mostly some refactors in the singleton_server to make the lifecycle work.
Adds an stdin/out json rpc server for wsl.
Exposes a singular install_local command to install+boot the vscode server on a port from a local archive.
Also refines the common rpc layer some more. I'm decently happy with it now.
This uses a hash of the tunnel ID to create the connection token, which
should be sufficient to resolve the issues.
We also now publish the protocol version in the tunnel tags, since the
connection token must be supplied in the resolver, which is before we
start connecting to the tunnel.
See https://github.com/microsoft/vscode-internalbacklog/issues/3287
Adds support for running the tunnel as a service on macOS via launchservices.
It also hooks up observability (`code tunnel service log`) on macOS and Linux.
On macOS--and later Windows, hence the manual implementation of `tail`--it
saves output to a log file and watches it. On Linux, it simply delegates to
journalctl.
The "tailing" is implemented via simple polling of the file size. I didn't want
to pull in a giant set of dependencies for inotify/kqueue/etc just for this use
case; performance when polling a single log file is not a huge concern.
systemd, like most 'modern' linux components, has a nice dbus API. This uses
that API to register the tunnel as a service of the calling user.
The dbus dependency is temporarily duplicated, until secret-service 3 is
released, where they update to the latest version (should be a week or two).
For https://github.com/microsoft/vscode-cli/issues/367. Next up, macOS,
then it's done :)
Implements an automatic local download fallback, similar to SSH
(cc @roblourens). If the initial download results in an error, either
in making the request or a 5xx, it'll try to fall back to making the
request locally and streaming it over the tunnel.
This abstracts the request client behing a "SimpleHttp" trait which
either uses to the native reqwest or uses the 'delegated' mode over the
socket.
Connor Peet
Taiyo Sogawa
Martin Aeschlimann
Benjamin Pasero