4 ms·
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
by brazzy 2y ago
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.
- michaelt 2y 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!
- YoumuChan 2y agoAnd Lua's bytecode loader, recently discussed here: https://news.ycombinator.com/item?id=40830005 https://news.ycombinator.com/item?id=40830005
- Dylan16807 2y agoI 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.
- brazzy 2y agoYes, 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.