Precompiled binaries removed from serde v1.0.184

> (At one point serde_derive ran an untrusted binary for over 4 weeks across 12 releases before almost anyone became aware. This was plain-as-day code in the crate root; I am confident that professionally obfuscated malicious code would be undetected for years.)

> Pardon my snark, but every "security expert" that voiced their opinion over the last couple of days, yet failed to recognize the situation for almost a month, should reassess their reaction once the anger subsides.

I'm not a "security expert", but I wondered why I hadn't noticed this situation, since I have the habit of always diffing between the previous and the current version of the crates in ~/.cargo/registry/src whenever cargo tells me it downloaded a new version of a dependency, and a new binary file would stick out like a sore thumb. But real life has intruded for me in the last few weeks, and the last serde_derive on my ~/.cargo is still 1.0.166, so it seems I luckily avoided all this mess.

(Yes, I know that reviewing the code after it has already compiled is suboptimal, and obfuscated malicious code or even the "new dependency" trick could easily pass through my cursory inspection; but at least it can be reviewed by comparing it with the previous version, unlike a precompiled binary blob where even small changes can lead to a huge difference between one binary and the other, not to mention that comparing objdump disassembly output is painful.)

If dtolnay planned ahead of time and indeed expected everything, kudos to him, because he had the guts to trade his credence with public good (I don't). That said, I would appreciate a confirmation that this is a very exceptional stunt that won't be repeated again.

> reassess their reaction once the anger subsides.

You have completely missed the point. It is because things go unnoticed that security minded folks are upset. We don't get off from finding security problems, we get off on being safe to begin with.

> before almost anyone became aware

This isn't a serious comment. It really does not matter whether "almost anyone" became aware, it matters whether the sorts of people who pay attention to this became aware. OS packagers became aware of this super quickly and were working quietly to get this fixed. My understanding is that some security teams at large companies quickly flagged this as well and likely reached out via private channels.

The public outrage happened weeks later but it's not as if no one was paying attention.

Isn't this exactly the kind of adversarial behavior that got the University of Minnesota banned from contributing to the Linux kernel? Made an intentionally bad-faith commit, then released it in order to prove a point about how insecure the software ecosystem is?

Great, he made his point that we're all dummies and we'll all just blindly run any ol' code he sends us. In the process he did very serious damage to his reputation and any trust relationship he had with the broader community. Other projects have banned people for this kind of behavior.

I disagree that what was done with good but agree with matklad [0] about basic expectations of transparency and communication when you maintain de facto standards. This is too big of an "experiment" to run in production code on the ecosystem without first seeking input of drawing attention to it. If any of this was done to "push the conversation forward", it is done in an unhealthy way that burns a lot of bridges.

As for making progress on the idea of improving build times, I agree with kayabaNerve from the Pre-RFC [1]

> It's effectively impossible to fairly review this on its merit now, nor to say it isn't being reviewed on an accelerated time span than it would otherwise have been.

[0] https://www.reddit.com/r/rust/comments/15va70a/serde_has_sta...

[1] https://internals.rust-lang.org/t/pre-rfc-sandboxed-determin...

Isn't that a parallel concern? The dependency chain is a separate issue from just building serde_derive itself isn't it?

It makes a lot of users's crates faster to compile from scratch, and compile time is a common complaint in Rust. It could be celebrated as a big total ecosystem win for compilation speed, but other issues overshadowed the whole thing.

Some gains and losses are elaborated here where it was added: https://github.com/serde-rs/serde/pull/2514

I did not know you can block people on github. The blocked people can't even fork?

>Interesting to see how glorified janitorial roles make people think they have some real power.

>Just take a look at https://github.com/andreisilviudragnea/serde-blocked/discuss...

>David went on a full on power trip rampage, going as far as banning people who participated with emojis on that PR from the serde org on GitHub.

Yeah... I'm going to go ahead and assume there's a little more to it that you're telling us.

even if it's a 'glorified janitorial role', you ain't paying him for it, so I don't really understand your objection to him not wanting to deal with your feedback on it (especially if it's just participating in a dogpile and not actually a useful contribution).

> Interesting to see how glorified janitorial roles make people think they have some real power.

Not hard to imagine why he would have blocked you or the possibility you're not telling the whole story. This combination of entitlement and disregard is thoroughly toxic.

dtolnay has built an incredible amount of the Rust ecosystem. For anyone unfamiliar, just take a look here: https://crates.io/users/dtolnay?sort=recent-downloads

Some of his crates are a bit opinionated, and I don't agree with all the opinions, but the amount of effort and ingenuity that has gone into them is breath-taking, and we get the results of it without paying a dime. Maybe that deserves some gratitude and grace...

> glorified janitorial roles

yeah, i'm quite supportive of him banning you.

I block all emoji users.