fix: avoid problematic serde release #15482
Conversation
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to function, explicitly not providing a library-level opt-out. This is problematic for two reasons: - directly, unauditable binary blobs are a security issue. - indirectly, it becomes much harder to predict future behaviors of the crate. As such, I am willing to go on a limb here and forbid building rust-analyzer with those versions of serde. Normally, my philosophy is to defer the choice to the end user, but it's also a design constraint of rust-analyzer that we don't run random binaries downloaded from the internet without explicit user's concent. Concretely, this upper-bounds serde for both rust-analyzer workspace, as well as the lsp-server lib. See serde-rs/serde#2538 for wider context.
rustbot
added
the
S-waiting-on-review
lnicola
left a comment
lnicola
left a comment
There was a problem hiding this comment.
I don't know for how long we can keep it like this, but sure, let's see what happens.
Too bad, though 😞.
|
I didn't look closely, can we build our own version of the blob and run it instead? EDIT: doesn't seem like it. |
|
I doubt pinning the version will cause us problems given most people seem to do the same currently. @bors r+ |
|
Practically, I would thing that just sticking to 171 should be fine, I don’t thing we need latest and greatest serde. for compile-time, the bigger problem for us is not that serde is slow to compile, but that it generates a loooot of code. Long term, my plan always was to remove serde in favor of directly generateing slow-but-fast—to-compile code from LSP meta model |
|
☀️ Test successful - checks-actions |
Notably this pins serde at 1.0.171, see context: rust-lang/rust-analyzer#15482
|
Learned about serde-rs/json#745. On a quick look, that sort of thing could be a major win for us. Also, serde-rs/serde#2250 (review) has a lot of valuable context. |
6 participants
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to function, explicitly not providing a library-level opt-out.
This is problematic for two reasons:
As such, I am willing to go on a limb here and forbid building rust-analyzer with those versions of serde. Normally, my philosophy is to defer the choice to the end user, but it's also a design constraint of rust-analyzer that we don't run random binaries downloaded from the internet without explicit user's concent.
Concretely, this upper-bounds serde for both rust-analyzer workspace, as well as the lsp-server lib.
See serde-rs/serde#2538 for wider context.