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 vscode-encrypt from node.js side
Now that we've had a version of the product that has done the migration logic, we no longer need vscode-encrypt on the node side.
This removes all references of vscode-encrypt from the node side. I will also remove it from the package.jsons in distro.
* remove machineId
* Have auth proxy use application storage service
Since this code is already using the encryption service, it already takes advantage of the better encryption provided by Electron so it can be stored in the normal storage service.
With that said, we do need a migration path, so this handles that migration.
* re-encrypt to force using the new electron algorithm
* it should already be removed from the old location
To start the migration process, we have `getCurrentAuthenticationSessionInfo` take in a `secretStorageService` and also replaces the `LocalStorageCredentialProvider` with a `LocalStorageSecretStorageProvider`.
After this goes in we can then update all embedders (vscode.dev, github.dev, Codespaces, vscode-web-test?) and replace ICredentialProvider usages with ISecretStorageProviders and then once we do that, we can get rid of a bunch of code!
This implements basically the same 'loopback' that vscode.dev does via
a service worker to load resources for managed remote authorities in
Electron. Except instead of using a service worker, it uses a buffer
protocol via a new 'vscode-managed-remote-resource' scheme. It finds
the window that the request came from and asks it to load the remote
file.
I initially looked at folding it into the existing 'vscode-remote-resource'
scheme, but we needed a "buffer protocol" for this and it seems http
protocols can _only_ respond with an HTTP URL, which we don't want here.
* added notification in case of running a rosetta translated build
* using app.runningUnderARM64Translation instead of system call
* added download button to the download page in the wrong build notification
* removed test call
* Update src/vs/workbench/electron-sandbox/window.ts
Co-authored-by: Robo <hop2deep@gmail.com>
* Update src/vs/workbench/electron-sandbox/window.ts
Co-authored-by: Robo <hop2deep@gmail.com>
* code format
* Update src/vs/workbench/electron-sandbox/window.ts
Co-authored-by: Robo <hop2deep@gmail.com>
---------
Co-authored-by: Robo <hop2deep@gmail.com>
* First move off of keytar
Since keytar is now deprecated, we need a solution going forward. That solution is the electron safeStorage API.
This PR:
* Uses the Electron safeStorage API for encryption
* Since we have encrypted strings we then store them in the StorageService (at the application & machine level)
This PR also refactors things quite a bit... a diagram of the change is going to be in the PR.
It gives embedders the ability to override the behavior of the secret storage similar to the existing Credential Provider embedder API... only with a better API surface since we no longer need to conform to keytar's shape.
More will come after this PR such as:
* Converting all CredentialService usages to SecretStorageService usages
After a while:
* Removing MainThreadKeytar
* Removing all the old code marked in this PR
* Use InMemoryStorageService
* use pausable emitter
* Encode folder paths as URI components.
This should prevent issues when trying to open folder paths that contain
special characters like `+` or `&`.
* 💄
---------
Co-authored-by: Benjamin Pasero <benjamin.pasero@gmail.com>
Tyler James Leonhardt
Benjamin Pasero
Connor Peet
Matt Bierner
Logan Ramos
Sandeep Somavarapu
Simon Siefke
Robo
Henning Dieterichs
Antonio PrudenzanoandRobo
Daniel Imms
Tilman RoederandBenjamin Pasero