Hacker News Reader

Comment by veec_cas_tant | Hacker News Reader

Authors comment:

>"Someone else is always auditing the code and will save me from anything bad in a macro before it would ever run on my machines." (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.)

He got some hate for that in the replies but I think it is a great point. 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.

The current macro situation is dangerous (and wasteful), hopefully some real progress can be made.

View on HN

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

I think it raises the question if “yeah, it can be done in theory, but rarely is, and even then is unlikely to effectual” is worth the trade offs?

I’m a purist personally, but I can see the other side

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

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

But the whole reaction here was 'this makes it more difficult to find security problems' (running a binary is not intrinsicly a security problem, if instead you are just going to compile it and then run it, it's just harder to audit a binary) and yet no-one was even doing the easy bit (auditing the source code). If someone had injected malicious code into the build.rs file it would have exactly the same effect.

> yet no-one was even doing the easy bit (auditing the source code).

Someone did: the Fedora maintainer who raised the issue. One of the reasons I avoid installing from wild-west package managers like Cargo/NPM/..., is specifically because Debian/Fedora/... maintainers performs some basic checks like this so I don't have to.

The fedora/rhel builds also go through virus/malware / security checks as part of the release process.

Each exception needs to be documented and specific.

Respectfully, I think we agree? The current proc macro situation allows security vulnerabilities and a potentially dangerous change went unnoticed for weeks. This RFC aims to address that, at least in part. If the comments I read reflected your view, I wouldn't have made my snarky remark. Unfortunately, I read many comments full of fury aimed at dtolnay while ignoring the system that enabled it.

I agree with the comments about dtolnay's decision and lack of communication here.

Oh, I misunderstood. I believe you are missing the forest for the trees but can't fault you for feeling angry if you believe trust was broken.

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.

Not exactly, UofM was accused of deliberately contributing security flaws to the Linux kernel. dtolnay proved a point, but it's not like his binary included a malicious payload.

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.

I don’t see how it affects our conclusions whether or not he planned it ahead of time. The facts about who is checking what are unchanged.

The conclusion remains unchanged, but it did show his bravery no matter you do like it or not.

Reply on news.ycombinator.com