This PR introduces a separate backend service for making LLM calls.
It exposes an HTTP interface that can be called by Zed clients. To call
these endpoints, the client must provide a `Bearer` token. These tokens
are issued/refreshed by the collab service over RPC.
We're adding this in a backwards-compatible way. Right now the access
tokens can only be minted for Zed staff, and calling this separate LLM
service is behind the `llm-service` feature flag (which is not
automatically enabled for Zed staff).
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR adds support for a new encryption format for exchanging access
tokens during the authentication flow.
The new format uses Optimal Asymmetric Encryption Padding (OAEP) instead
of PKCS#1 v1.5, which is known to be vulnerable to side-channel attacks.
**Note: We are not yet encrypting access tokens using the new format, as
this is a breaking change between the client and the server. This PR
only adds support for it, and makes it so the client and server can
decrypt either format moving forward.**
This required bumping the RSA key size from 1024 bits to 2048 bits. This
is necessary to be able to encode the access token into the ciphertext
when using OAEP.
This also follows OWASP recommendations:
> If ECC is not available and RSA must be used, then ensure that the key
is at least 2048 bits.
>
> —
[source](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#algorithms)
Release Notes:
- N/A
Note:
- We have disabled all tests that rely on Postgres in the Linux CI. We
only really need to test these once, and as macOS is our team's primary
platform, we'll only enable them on macOS for local reproduction.
- We have disabled all tests that rely on the font metrics. We
standardized on Zed Mono in many fonts, but our CoreText Text System and
Cosmic Text System proved to be very different in effect. We should
revisit if we decide to standardize our text system across platforms
(e.g. using Harfbuzz everywhere)
- Extended the condition timeout significantly. Our CI machines are slow
enough that this is causing spurious errors in random tests.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR provides some of the plumbing needed for a "remote" zed
instance.
The way this will work is:
* From zed on your laptop you'll be able to manage a set of dev servers,
each of which is identified by a token.
* You'll run `zed --dev-server-token XXXX` to boot a remotable dev
server.
* From the zed on your laptop you'll be able to open directories and
work on the projects on the remote server (exactly like collaboration
works today).
For now all this PR does is provide the ability for a zed instance to
sign in
using a "dev server token". The next steps will be:
* Adding support to the collaboration protocol to instruct a dev server
to "open" a directory and share it into a channel.
* Adding UI to manage these servers and tokens (manually for now)
Related #5347
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
This reduces the server time to compute the hash from 40ms to 5µs,
which should remove this as a noticable chunk of CPU time in production.
(An attacker who has access to our database will now need only 10^54
years of CPU time instead of 10^58 to brute force a token).
Release Notes:
- Improved sign in latency by 40ms.
This PR replaces a `lazy_static!` usage in the `collab` crate with
`OnceLock` from the standard library.
This allows us to drop the `lazy_static` dependency from this crate.
Release Notes:
- N/A
* Use the impersonator id to prevent these tokens from counting
against the impersonated user when limiting the users' total
of access tokens.
* When connecting using an access token with an impersonator
add the impersonator as a field to the tracing span that wraps
the task for that connection.
* Disallow impersonating users via the admin API token in production,
because when using the admin API token, we aren't able to identify
the impersonator.
Co-authored-by: Marshall <marshall@zed.dev>
This avoids the cost of hashing an access token multiple times,
to compare it to all known access tokens for a given user.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
Over time, I think we may end up having multiple services, so it seems like a good opportunity to name this one more specifically while the cost is low. It just seems like naming it "zed" and "zed-server" leaves it a bit open ended.
