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
* 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
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
