-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: avoid problematic serde release #15482
The head ref may contain hidden characters: "\u{1FA84}deblobify"
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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.