> (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 cr

> (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.)