Rust devs push back as Serde project ships precompiled binaries

The issue has now been locked and no further conversation can take place on it. This is without a further comment.<p>I found the discussion to be mostly very civilized and focused on finding solutions for those affected.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;issues&#x2F;2538">https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;issues&#x2F;2538</a><p>It&#x27;s all the right of the author. And he&#x27;s done so before.<p>Unfortunately, I&#x27;m afraid this could lead to a more fragmented ecosystem which is a pity.<p>It takes a long time to build trust but it can be destroyed quickly. I&#x27;m not sure if the author cares about that though. From my reading of the comments he doesn&#x27;t.<p>&quot;If there is implementation work needed in some build tools to accommodate it, someone should feel free to do that work (as I have done for Buck and Bazel, which are tools I use and contribute significantly to) or publish your own fork of the source code under a different name.&quot;<p><a href="https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;issues&#x2F;2538#issuecomment-1682519944">https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;issues&#x2F;2538#issuecomment-1...</a><p>This is so sad.

People have complained about the build time of proc macros for ages in the community. This might be a misguided hack, but the response to this is bordering on a witch hunt, particularly when there is a glaring security hole (build.rs) that most people likely use without second thought every single day. I simply do not believe that most people commenting on this issue are auditing the builds of all their transitive dependencies.

I dislike some of the framing of the article. In particular:<p>&gt; Valentini further inquired to the project maintainers, how were these new binaries &quot;actually produced,&quot; and if it would be possible for him to recreate the binaries, as opposed to consuming precompiled versions. David Tolnay, who is the primary Serde maintainer, responded with potential workarounds at the time.<p>The article links to the response [1] as well, which is very good. However, the response doesn&#x27;t provide workarounds. It provides clear instructions:<p>&gt;&gt; how is the x86_64-unknown-linux-gnu binary actually produced? Would it be possible for us to re-create the binary ourselves so we can actually ship it?<p>&gt; By <a href="https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;blob&#x2F;v1.0.177&#x2F;precompiled&#x2F;build.sh">https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;blob&#x2F;v1.0.177&#x2F;precompiled&#x2F;...</a>. Yes.<p>When the article states that the library author only provided &quot;potential workarounds&quot;, it sounded really shady to me, and I believe this is mischaracterizing the real response.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;issues&#x2F;2538#issuecomment-1654783988">https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;issues&#x2F;2538#issuecomment-1...</a>

On the argument of &quot;you&#x27;re not reading build.rs anyway&quot;: yes, but you <i>can</i>, and that&#x27;s a critical difference.<p>&quot;No one&quot; is validating all their transitive dependencies for weird binaries, except a few people, and that&#x27;s enough to get us all here talking about it. In the internet age it only takes one. But if you make it require more work to inspect a blob, you reduce the chances that you&#x27;ll get even that one person who sounds the alarm. At minimum malicious code will survive longer that way.

Plenty of projects ship binaries without a problem. Nearly every Linux distribution, for example. What’s special about Rust in that binaries for dependencies are a problem?<p>Also, for the “why” - is it just the very slow build times for Rust?

I&#x27;m curious whether those with more professional exposure to rust are concerned about this or think it&#x27;s noisy for no reason?<p>I&#x27;d also be curious if anyone has any good explanations as to why a choice like this would be made?

I don&#x27;t understand why this is so complex? Just make it a feature you put in Cargo.toml:<p>serde = { version = &quot;1.0&quot;, features = [&quot;serde_derive&quot;, &quot;fast_compile&quot;] }<p>Either opt-in or opt-out is fine. It&#x27;s surely useful during development but it shouldn&#x27;t be on for production builds. Any transitivity issues should be considered problems with the dependency.

Update: Removed in v1.0.184 (<a href="https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;releases&#x2F;tag&#x2F;v1.0.184">https:&#x2F;&#x2F;github.com&#x2F;serde-rs&#x2F;serde&#x2F;releases&#x2F;tag&#x2F;v1.0.184</a>)

Regardless of the circumstances, non-optional binary dependencies doesn’t pass the smell test

Could be neat if serde (and other libraries with proc macros) were able to ship WebAssembly blobs. Wasm blobs are portable and run with restricted capabilities. Rustc could expose an embedded API to allow the wasm to generate code and expand macros without hitting the network.

The sketchy part is it was changed and shipped silently and in a sneaky way, and if it wasn’t for some developer to notice it, he wouldn’t have mentioned it.. However, no need to pushback or anything, consider the maintainer got hit by a bus, fork it, and take it from there.<p>Also, the “security” guy claiming no one is going to read it, do you read linux kernel every update? No, not you, but other developers do, or whenever someone is interested&#x2F;auditing they can, that kind of arguments are stupid.

Rubygems have been doing this for about a decade now to provide precompiled binaries for Windows systems in particular (generally while compiling native extensions on Linux at install time, although sometimes shipping precompiled binaries for most every target for speed + decoupling the build environment).

What problem does using precompiled binaries solve for serde?

serde is bloated anyway. see for yourself:<p>146 kB: <a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;serde_json" rel="nofollow noreferrer">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;serde_json</a><p>43 kB: <a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;sj" rel="nofollow noreferrer">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;sj</a><p>29 kB: <a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;humphrey_json" rel="nofollow noreferrer">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;humphrey_json</a><p>7 kB: <a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;rust_json" rel="nofollow noreferrer">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;rust_json</a>

Will this be considered a breaking change according to the SemVer conventions?

Java ships everything with JARs, though? Binary.

dupe of <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37183361">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37183361</a>

chrome-on-linux visit to that bleepingcomputer site, prompted for an xdg-open of an external app?

As far as I&#x27;m concerned pre-compiled binaries should only be offered as potential default in scripting language ecosystems - there is an expectation that things should &quot;just work&quot;.<p>I don&#x27;t mind it for when I work in Node - honestly I prefer it. But in Rust? The entire toolchain is designed to compile from source. It may be a bit slow for certain crates still, but that&#x27;s much weaker justification to make pre-compiled the default.<p>Crates should compile from source by default as long as source actually exists (ex. has not been lost somehow, or wide distribution of the crate is unlikely). I don&#x27;t buy any of the malicious theories since the author is well appreciated and respected. It&#x27;s likely just a misguided choice in this case.<p>People have rightly mentioned build.rs flexibility - I think there is nuance here and maybe it&#x27;s good to discuss what default behavior should be expected by users, since sometimes build.rs does wild and useful things.