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.
Previously we only tried to recycle a tunnel once, so if the tunnel
limit changed and was reduced by >1 we'd fail even though we should
have actually just recycled multiple tunnels.
Also, only trigger recycling if the specific tunnel limit is hit.
* 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
Adds a 5s timeout to keychain access on Linux. We had an issue about this a long time ago, but I never repro'd it until today and can't find the original...
If this timeout is hit, it'll fall back to the file-based keychain.
* cli: ensure ordering of rpc server messages
Sending lots of messages to a stream would block them around the async
tokio mutex, which is "fair" so doesn't preserve ordering. Instead, use
the write_loop approach I introduced to the server_multiplexer for the
same reason some time ago.
* fix clippy
* 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
* cli: store cli in user data dir, separate per quality
Fixes#181017
On first run, the `~/.vscode-cli` will be migrated inside the user data dir of the currently running quality.
* use create_dir_all instead
* clippy fixes
Last iteration I moved some RPC logic to use Tokios "codecs" to give
them cancellation safety. These operate on streams of input data.
While this worked at first, I failed to take into account that the byte
buffer we read from the stream could have _more_ data than just the
current message under load scenarios. We were discarding any extra data
from the subsequent message. In most cases caused the next message
"length" to be read from the middle of the next message, which usually
(when parsed as a u32) was some number of gigabytes, then causing the
connection to stall forever.
Fixes#181284
* fix: don't sync debug.lastExtensionDevelopmentWorkspace
* cli: fix attach does not always work
Seems like reading stdin when it's open but never written to blocks the process. Fix that, both by checking IS_INTERACTIVE_CLI before reading stdin, and by not passing stdin to the tunnel subprocess.
Fixes#179122
* testing: another fix to avoid automatically queuing
Fixes#180041 again
* cli: only show other interactive attach commands when in a terminal
Fixes#178091
* cli: add acquire_cli
As given in my draft document, pipes a CLI of the given platform to the
specified process, for example:
```js
const cmd = await rpc.call('acquire_cli', {
command: 'node',
args: [
'-e',
'process.stdin.pipe(fs.createWriteStream("c:/users/conno/downloads/hello-cli"))',
],
platform: Platform.LinuxX64,
quality: 'insider',
});
```
It genericizes caching so that the CLI is also cached on the host, just
like servers.
* fix bug
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.
* option to disable encryption of keys
Avoids issue of token invalidation when switching machines with a shared home directory, as suggested by @connor4312 in https://github.com/microsoft/vscode-remote-release/issues/8110#issuecomment-1452270922Fixes#8110
* Update cli/src/auth.rs
Co-authored-by: Connor Peet <connor@peet.io>
* Change variable to VSCODE_CLI_DISABLE_KEYCHAIN_ENCRYPT
Co-authored-by: Connor Peet <connor@peet.io>
---------
Co-authored-by: Connor Peet <connor@peet.io>
Fixes#167708 by using a more predictable naming scheme.
```
me> Write a haiku about the extinction of birds
chatgpt>
Silent skies above,
Once lively songs now gone,
Fading memories.
```
Fixes#167741
This eschews the offical Windows service system in favor of registering
into `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run`.
Unlike services, this can be done without administrative permissions,
does not require the current username/password, and is not blocked by
miscellaneous and mysterious system policies.
Since the process is basically unmanaged by the OS, this requires a
little legwork to start and stop the process when registering and
unregistering.
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.
I want to use the rpc interface for communication via stdin/out in wsl,
but currently RPC is tightly coupled to the control server. The control
server also speaks msgpack instead of JSON, since it deals with binary
messages. WSL won't, and we'll want to use JSON to interact with VS
Code, so some separation is needed.
This pulls out a base set of RPC types for use in both scenarios.
Currently these are only 'helper' structs that don't actually do any
i/o, but once I figure out the model I would like to have a cleaner way
to do i/o in a unified way as well.
For the control server, previously we basically handled all methods in
one big `switch` block with nasty macros, whereas now there's
nicer `register_a/sync` functions.
Some additional small refactors were needed to preserve the strict
ordering of server messages, since they need to be order else we get
decompression errors. This is the `start_bridge_write_loop`. As a small
benefit, this means we can avoid the relatively expensive async Tokio
mutex that we were using, and instead use the standard library mutex.
