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.
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.
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 :)
This is the CLI side of enabling compression of servermsg's sent
over the socket. It is feature-detected by the CLI sending
protocolVersion=2. If present, the consumer can request compression by
passing `compress:true` when setting up the server.
In this mode, servermsg's are an inflate/deflate stream. Not a ton of
code here, but was lots of fun tweaking to get it right :)
Fixes https://github.com/microsoft/vscode/issues/163688
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.
Previously the control server could only handle a single request at a
time. To enable local download mode, this needs to change as the client
will be sending data to the CLI as it downloads the vscode server zip.
This does that. There's a little mess since things that async handlers
need to use are cloned out of the previously unified "context" (we
could try and clone the whole context each time, but this is more work
than needed.) We still keep the fast things as "blocking" since that
avoids the need for clones and separate tasks.
The standalone CLI should detect and fall back to using and
system-installed VS Code instance, rather than trying to download zips
and manage its own VS Code instances.
There are three approaches used for discovery:
- On Windows, we can easily and quickly read the register to find
installed versions based on their app ID.
- On macOS, we initially look in `/Applications` and fall back to the
slow `system_profiler` command to list app .app's if that fails.
- On Linux, we just look in the PATH. I believe all Linux installers
(snap, dep, rpm) automatically add VS Code to the user's PATH.
Failing this, the user can also manually specify their installation dir,
using the command `code version use stable --install-dir /path/to/vscode`.
Fixes#164159
- Start separating a "standalone" CLI. This is a little awkward with clap-
derive, but I got it working. Detection of whether the CLI _is_
standalone is still todo.
- Remove the old ad-hoc update code for code-server, and use the update
service instead.
- Fix some of the "permission denied" errors people got while updating
before. We need to rename the old running binary, not just overwrite it.