Libxml2's "no security embargoes" policy

An AV system stopping because of a bug in a library is bad, but that's not because the library has a security bug. It's a security problem because the system itself does security. It would be wild if any bug that leads to a crash or a memory leak was a "security" bug because the library might have been used by someone somewhere in a context that has security implications.

A bug in a library that does rate limiting arguably is a security issue because the library itself promises to protect against abuse. But if I make a library for running Lua in redis that ends up getting used by a rate limiting package, and my tool crashes when the input contains emoji, that's not a security issue in my library if the rate limiting library allows emails with punycode emoji in them.

"Hogging all of the resources on a shared system" isn't a security bug, it's just a bug. Maybe an expensive one, but hogging the CPU or filling up a disk doesn't mean the system is insecure, just unavailable.

The argument that downtime or runaway resource use due is considered a security issue but only if the problem is in someone else's code is some Big Brained CTO way of passing the buck onto open source software. If it was true, Postgres autovacuuming due to unpleasant default configuration would be up there with Heartbleed.

Maybe we need a better way of alerting downstream users of packages when important bugs are fixed. But jamming these into CVEs and giving them severities above 5 is just alert noise and makes it confusing to understand what issues an organization should actually care about and fix. How do I know that the quadratic time regexp in a string formatting library used in my logging code is even going to matter? Is it more important than a bug in the URL parsing code of my linter? It's impossible to say because that responsibility was passed all the way downstream to the end user. Every single person needs to make decisions about what to upgrade and when, which is an outrageous status quo.

DoSing autonomous vehicle brake controls...

Well, that's sort of the problem.

It's true that once upon a time, libxml was a critical path for a lot of applications. Those days are over. Protocols like SOAP are almost dead and there's not really a whole lot of new networking applications using XML in any sort of manor.

The context where these issues could be security bugs is an ever-vanishing usecase.

Now, find a similar bug in zlib or zstd and we could talk about it being an actual security bug.

If every single bug in libxml is a business ending scenario for the bank, then maybe the bank can afford to hire someone to work on those bugs rather than pestering a single volunteer.

Many of these issues are not the type of issues that will bring down an entire platform; most are of the "if I send wrong data, the server will return with a 500 for that request" or "my browser runs out of memory if I use a maliciously crafted regexp". Well, whoopdeedoo.

And even if it somehow could, it's 1) just not the same thing as "I lost all my money" – that literally destroys lives and the bank not being available for a day doesn't. And 2) almost every bug has the potential to do that in at least some circumstances – circumstances with are almost never true in real-world applications.

Security and utility are separate qualities.

You’re correct that inaccessible money are useless, however one could make the case that they’re secure.

I routinely handle regex DoS complaints on front-end input validation…

If a hacker wants to DoS their own browser I’m fine with that.

I think it's context dependent whether DoS is on par with data loss/extraction, including whether it's actually a security issue or not. I would argue DoS for a bank (assuming it affects backend systems and not just the customer portal) would be a serious security issue given the kinds of things it could impact.

Not really. A company that does not bother contributing to a liberally-licensed project will 100% avoid GPL software like the plague. In either case, they won't contribute. In the latter case, they don't get to free-ride like a parasite.

The GPL does not prohibit anyone from using a piece of software. It exclusively limits the actions of bad faith users. If all people engaged with FOSS in good faith, we wouldn't need licenses, because all most FOSS licenses require of the acceptors is to do a couple of small, free activities that any decent person would do anyway. Thank/give credit to the authors who so graciously allowed you to use their work, and if you make any fixes or improvements, share alike.

Security issues like this are a prime example of why all FOSS software should be at least LGPLed. If a security bug is found in FOSS library, who's the more motivated to fix it? The dude who hacked the thing together and gave it away, or the actual users? Requesting that those users share their fixes is farrr from unreasonable, given that they have clearly found great utility in the software.

A decent part of my job is open source. Our reason for doing it is simple: we would rather have people who are not us do the work instead of us.

On some of our projects this has been a great success. We have some strong outside contributors doing work on our project without us needing to pay them. In some cases, those contributors are from companies that are in direct competition with us.

On other projects we've open sourced, we've had people (including competitors) use, without anyone contributing back.

Guess which projects stay open source.

When I, as a little child (or at least that is how it feels now), got excited about contributing to open source, it was not the thought that one day my code might help run some giant web platform's infrastructure or ship as part of some AAA videogame codebase that motivated me. The motivation was the idea that my code might be useful to people even with no corporation or business having to be involved!

So that if they find it useful, they will contribute their own improvements to benefit the project.

I don’t think many projects see acquiring unpaying corporate customers as a goal.

What’s the point in people using it if all that profit ends up in someone else’s pockets?

People can use it. Corporations won't. I'm entirely unbothered by this outcome.

This isn't a popularity contest and I'm sick of gamification of literally everything.

Trillion dollar corporations are not "people".

You can want to be helpful without wanting to have power or responsibility.

I'm interested in people (not companies, or at least I don't care about companies) being able to read, reference, learn from, or improve the open source software that I write. It's there if folks want it. I basically never promote it, and as such, it has little uptake. It's still useful though, and I use it, and some friends use it. Hooray. But that's all.

And whose fault is it? The person who gave their work for free, or the parasitic company that shipped a product with it?

At what rate though? Is it worth burning out devs we as a community rely upon because maybe someday 0.000001% of these bugs might have real impact? I think we need to ask more of these "security researchers". Either provide a real world attack vector or start patching these bugs along with the reports.

It was not however effective at getting the project to care about quality or performance.