undefined | Better HN

0 pointsbrazzy1y ago0 comments

That sounds... familiar. Are you perchance the maintainer of SnakeYAML?

Yes, it is correct to file a CVE of the highest priority against your project, because "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library.

If it's your toy project that you never expected anyone to use anyway, you don't care about CVEs. If you want to be taken seriously, you cannot play pass-the-blame and ignore the fact that your policy turns the entire project into a security footgun.

0 comments

michaelt1y ago

> "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library.

Truly, it's a design decision so ridiculous nobody else has made it. Except Python's pickle, Java's serialization, Ruby's Marshal and PHP's unserialize of course. But other than that, nobody!

brazzyOP1y ago

Yes, all of those languages made that bad decision back in the 90s and came to regret it. What's ridiculous is refusing to learn from that.

YoumuChan1y ago

And Lua's bytecode loader, recently discussed here: https://news.ycombinator.com/item?id=40830005

Dylan168071y ago

I know "code is data", but it's a couple orders of magnitude more reasonable to have unsafe bytecode than to have unsafe data deserialization.

If something is supposed to load arbitrary code, not just data, that needs to be super clear at a glance. If it comes across as a data library, but allows takeover, you have a problem. Especially if there isn't a similar data-only function/library.

j / k navigate · click thread line to collapse