49
Rust devs push back as Serde project ships precompiled binaries
(www.bleepingcomputer.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Aug 2023
49 points (96.2% liked)
Rust
5999 readers
7 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
Since it's open source, could someone fork off a drop-in replacement that compiles from source?
Edit: No need now:
https://github.com/serde-rs/serde/releases/tag/v1.0.184
TLDR: Forking is a hostile move, let us keep it as a last resort and start by communicating first.
Someone could, but it is much more complicate than that.
You will need to convince every crate that uses
serde(or at least every crate in your dependencies) to switch to your fork. Andserdeis extremely popular in the Rust community, you would be quite busy.You will need to reach out to every author of a crate depending on
serde. Some of them will not be aware of this problem. Some will not understand why this is a problem. Some will agree with the current implementation. Some will refuse to switch in order to avoid splitting the community.And the split is going to happen anyway, because many will not switch due to these points.
Then you will have to maintain such fork, which might or might not be a particularly time-consuming job for a particular project, but it is a job nonetheless.
Also, just straight forking a project is a quite hostile move. The proper way to handle this is to contact the maintainer, ask why this change was made, and start a discussion arguing the drawbacks and asking to revert it.
It is also worth mentioning that the maintainer of
serdeis very active in the Rust community, and they maintain a lot of other popular crates. Just to name a few:anyhow,async-trait,semver,syn,thiserror. They are definitely an important member of the community, and a very experienced one. They are not immune from mistakes, of course, but I think we would be much better off by talking to them than just assuming bad faith and hijacking their project.Diplomacy goes a long way, and I would be very surprised to find out that they are completely unreasonable with respect to this issue (from my limited interaction with them, they seem a rather decent person).
Meanwhile, we can pin a version of
serdethat does not have this issue. There is no need to rush.That has already occurred. The maintainer pretty much ignored the question, as far as I can tell.
People usually behave that way when they have an ulterior motive. In this case, I worry that the plan is to slip some malware into that binary…
The maintainer took a very FOSS approach of "this is better and the tools we use don't support better choices, so you're welcome to fix the tools."
If the binary matched the source code, that argument would hold, but it doesn't, which is sounding alarm bells in my head. Just what is in those 600 kilobytes of machine code?
Well said. I imagine that maintaining a project as ubiquitous as
serdeis not an easy job, and I'm sure dtolnay is no stranger to holding his ground when people disagree with him. I'm therefore not that surprised to see him holding his ground on this issue, and I think people should still continue the discussion with him instead of immediately forking.I personally think that proposing a PR to allow opting out of this (as is being hashed out here: https://github.com/serde-rs/serde/pull/2580) is a much better solution than forking. In my experience in open source dev, writing a PR often produces much better results than just complaining in an issue.
That's a great answer - thanks. I agree that communication is the first thing to try. Realistically a fork would just result in multiple versions of the same thing kicking around, including the binary that worries people.
Edit: Seems like diplomacy worked. The developer is removing the precompiled binary:
https://github.com/serde-rs/serde/releases/tag/v1.0.184
I've been pinning my projects with the code in https://github.com/rust-lang/miri/pull/3032
In particular, the important part is:
Which both avoids the conflicts an
=versionpin would produce and ensures all your dependencies with ranged serde versions will use a version without the binary if possible ^.^The developer has agreed to remove the precomputed binary in v1.0.184:
https://github.com/serde-rs/serde/releases/tag/v1.0.184
Awesome!
Gotta figure a way to avoid the specific versions but I'm glad they relented ^.^
"<" should be a less-than sign, but it gets delimited into HTML magic character codes for some reason but only inside a code block? >.<
Yeah, I've noticed this happening elsewhere on Lemmy instances, too.