* 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.
Fixes https://github.com/microsoft/vscode/issues/167760
The VS Code CLI gets run from a bash/shell script. This prevents interactions--in the former case, it doesn't look like a tty, and in the latter case batch scripts don't seem to support having interactive subprocesses.
This PR avoids interactions if stdin is not a tty, prompting the user to use the flag instead. Use of the flag is also persisted like an interactive agreement prompt.
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
A fully-functioning CLI with tunnel capabilities requires product-specific
configuration that is not included in the OSS. This change has the CLI's build
script automatically look for a peer `vscode-distro` folder and, in a debug
build, set its build variables based on that.
It also works to set correct variables if vscode-distro is not found, based on
the OSS product.json (though this is not sufficient to run a fully fledged
tunnel.)
Fixes https://github.com/microsoft/vscode-cli/issues/563
If a new tunnel `--name` was provided but the existing tunnel was deleted,
the CLI would error out with a lookup failed message. Instead it now
recreates it like it normally would.
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.