Things like "panics on certain content" like [1] or [2] are "security bugs" now. By that standard anything that fixes a potential panic is a "security bug". I've probably fixed hundreds if not thousands of "security bugs" in my career by that standard.
Barely qualifies as a "security bug" yet it's rated as "6.2 Moderate" and "7.5 HIGH". To say nothing of gazillion "high severity" "regular expression DoS" nonsense and whatnot.
And the worst part is all of this makes it so much harder to find actual high-severity issues. It's not harmless spam.
[1]: https://github.com/gomarkdown/markdown/security/advisories/G...
The maintainer claims this is caused by allocator failure (malloc returning null), but it is still a valid bug. If you don't want to deal with malloc failures, just crash when malloc() returns null, instead of not checking malloc() result at all.
The maintainer could just write a wrapper around malloc that crashes on failure and replace all calls with the wrapper. It seems like an easy fix. Because almost no software can run where there is no heap memory so it makes no sense for the program to continue.
Another solution is to propagate every error back to the caller, but it is difficult and there is high probability that the caller won't bother checking the result because of laziness.
A quote from a bug report [1]:
> If xmlSchemaNewValue returns NULL (e.g., due to a failure of malloc), xmlSchemaDupVal checks for this and returns NULL.
So could the reporter of the bug. Alternatively, he could add an `if(is null){crash}` after the malloc. The fix is easy for anyone that has some knowledge of the code base. The reporter has demonstrated this knowledge in finding the issue.
If a useful PR/patch diff was provided with the reporter, I would have expected it to be merged right away.
However, instead of doing the obvious thing to actually solve the issue, the reporter hits the maintainer with this bureaucratic monster:
> We'd like to inform you that we are preparing publications on the discovered vulnerability.
> Our Researchers plan to release the technical research, which will include the description and details of the discovered vulnerability.
> The research will be released after 90 days from the date you were informed of the vulnerability (approx. August 5th, 2025).
> Please answer the following questions:
>
> * When and in what version will you fix the vulnerability described in the Report? (date, version)
> * If it is not possible to release a patch in the next 90 days, then please indicate the expected release date of the patch (month).
> * Please, provide the CVE-ID for the vulnerability that we submitted to you.
>
> In case you have any further questions, please, contact us.
https://gitlab.gnome.org/GNOME/libxml2/-/issues/905#note_243...
The main issue here is really one of tone. The maintainer has been investing his free time to altruistically move the state of software forward and the reporter is too lazy to even type up a tone-adjusted individual message. Would it have been so hard for the reporter to write the following?
> Thank you for your nice library. It is very useful to us! However, we found a minor error that unfortunately might be severely exploitable. Attached is a patch that "fixes" it in an ad-hoc way. If you want to solve the issue in a different way, could we apply the patch first, and then you refactor the solution when you find time? Thanks! Could you give us some insights on when after merging to main/master, the patch will end up in a release? This is important for us to decide whether we need to work with a bleeding edge master version. Thank you again for your time!
Ultimately, it is a very similar message content. However, it feels completely different.
Suppose you are a maintainer without that much motivation left, and you get hit with such a message. You will feel like the reporter is an asshole. (I'm not saying he is one.) Do you really care, if he gets powned via this bug? It takes some character strength on the side of the maintainer to not just leave the issue open out of spite.
I not think you can deal with the failure condition the way you think on Linux (and I imagine other operating systems too).
DoS results in whatever the system happens to do. It may well result in bad things happening, for example stopping AV from scanning new files, breaking rate limiting systems to allow faster scanning, hogging all resources on a shared system for yourself, etc. It's rarely a security issue in isolation, but libraries are never used in isolation.
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.
1. Serious. "This is a problem and it needs fixing yesterday."
2. Marketing. "We discovered that if earth had two moons and they aligned right and you had local root already you could blah blah. By the way we are selling this product that will generate a positive feedback loop for your paranoid tendencies, buy buy buy!".
3. Reputation chasing. Same as above, except they don't sell you a product, they want to establish themselves as an expert in aligning moons.
Much easier to do 2 or 3 via "AI" by the way.
This is so frustrating.
The claimed CWE-125 [2] has a description that says "The product reads data past the end, or before the beginning, of the intended buffer." -- which empirically does not happen in the Go Markdown parser issue. It panics, sure, but that doesn't result in any reads past the end, or before the beginning, of the intended buffer. Said another way, *there is no out-of-bounds read* happening here at all.
These kinds of false-positive CVE claims are super destructive to the credibility of the CVE system in general.
--
[1] https://github.com/gomarkdown/markdown/security/advisories/G...
A DoS affects the availability of an application, and as such is a real security bug. While the severity of it might be lower than a bug that allows to "empty bank accounts", and fixing it might get a lower priority, it doesn't make it any less real.
who decided that "availability" was part of security?
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.
> Denial of service is not resulting in ...
Turns out they result in deaths. (This was DoS through ransomware)
That is why I think that "severity" and the usual kinds of vulnerability scores are BS. Anyone composing a product or operating a system has to do their own assessment, taking into account all circumstances.
In the context of the original article this means that it is hopeless anyways, and the maintainer's point of view is valid: in some context everything is "EXTREMELY HIGH SEVERITY, PANIC NOW!". So he might as well not care and treat everything equally. Absolutely rational decision that I do agree with.
The library isn't a worm, it does not find its way into anything. If the bank cares about security they will write their own, use a library that has been audited for such issues, sponsor the development, or use the software provided as is.
You may rejoin with the fact that it could find its way into a project as a dependency of something else. The same arguments apply at any level.
If those systems crash because they balanced their entire business on code written by randos who contribute to an open source project then the organizations in question will have to deal with the consequences. If they want better, they can do what everyone is entitled to: they can contribute to, make, or pay for something better.
But a hospital? A bank? A stock broker? Some part of the military's stack?
Context is important, and what is innocuous to you may kill someone or cost millions if exploited in the wild elsewhere.
It would be profoundly difficult for a machine or a convention to understand everyone's context and be able to frame it correctly, so it's left to the developers to review what the security issues are and act accordingly.
I do agree the system should be improved and there's a lot of spam, but your blasé attitude toward what is or is-not a security issue seems off the mark.
Ackshually...
Security is typically(*) classified as CIA: Confidentiality, Integrity and Availability. Denial of Service is an attack against Availability... so yeah, that kind of is inherently a security bug.
Why? Because the memory corruption only happened if you manually called a semi-undocumented API. And that API was only there to support the profiler (gprof), so it being called manually almost never happened and wasn’t officially supported, in normal use the compiler would insert calls to it automatically in profiler builds and in normal production builds the undocumented API would never be called. So in practice this is impossible to exploit, except for apps which do weird things which almost nobody does (e.g. use profiler builds in production, and then expose a REST API to let a remote user stop/start the profiler at runtime)
And yet, now it is listed as a real vulnerability in umpteen security vendor databases. Because the CVE database just accepts anything as a vulnerability if someone claims it is, and if the developers disagree, they just mark it as “Disputed”. But then in my experience a lot of these vendors don’t treat Disputed vulnerabilities any differently, their code analysis tools will still flag them as a “security risk” even though the vast majority of them are BS
A denial of service in a system related to emergency phone calls can result on people's deaths.
That is not true at all. Availability is also critical. If nobody can use bank accounts, bank has no purpose.
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.
You’re correct that inaccessible money are useless, however one could make the case that they’re secure.
If a hacker wants to DoS their own browser I’m fine with that.
I suspect the maintainer would mind less if it was reported by actual users of the library who encountered a real world issue and even better if they offer a patch at the same time, but these bugs are likely the result of scanning tools or someone eyeballing the code for theoretical issues.
In light of the above, the proposed MAINTENANCE-TERMS.md makes a lot of sense, but I think it should also state that security researchers looking for CVEs or are concerned about responsible disclosure should contact the vendor of the software distributing the library.
This would put the onus on the large corporates leveraging the library (at no charge) to use their own resources to deal with addressing security researcher concerns appropriately and they can probably do most of the fix work themselves and the coordinate with the maintainer only to get a release out in a timely manner.
If maintainers find that people coming to them with security issues have done all work possible before hand, they’d probably be completely happy to help.
I'm only half-joking when I say that one of the premier selling points of GPL over MIT in this day and age is that it explicitly deters these freeloading multibillion-dollar companies from depending on your software and making demands of your time.
There isn't much difference between MIT and GPL unless you are selling a product that runs locally or on premisses and with the latter some companies try to work around GPL by renting servers with software on it - either as physical boxes or something provided on cloud provider marketplace.
Look at what you actually have installed on your computer - odds are that unless your job requires something like CAD, photo/video editing or other highly specialized software you have nothing made by large enterprise with exception of OS and Slack/Teams/Zoom.
Which is why we have the AGPL.
I find that hard to believe.
In short, Apple maintain a 448 kB diff which they 'throw across the wall' in the form of an opaque tarball, shorn of all context. Many of the changes contained within look potentially security-related, but it's been released in a way which would require a huge amount of work to unpick.
That level of effort is unfeasible for a volunteer upstream developer, but is a nice juicy resource for a motivated attacker. Apple's behaviour, therefore, is going to be a net negative from a security point of view for all other users of this library.
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.
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.
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.
I don’t think many projects see acquiring unpaying corporate customers as a goal.
This isn't a popularity contest and I'm sick of gamification of literally everything.
You owe them nothing. That fact doesn’t mean maintainers or users should be a*holes to each other, it just means that as a user, you should be grateful and you get what you get, unless you want to contribute.
Or, to put it another way: you owe them exactly what they’ve paid for!
Many open source developers feel a sense of responsibility for what they create. They are emotionally invested in it. They may want to be liked or not be disliked.
You’re able to not care about these things. Other people care but haven’t learned how to set boundaries.
It’s important to remember, if you’re not understanding what a majority of people are doing, you are the different one. The question should be “Why am I different?” not “Why isn’t everyone else like me?”
“Here’s the solution” comes off far better than, “I don’t understand why you don’t think like me.”
I used to work on a kernel debugging tool and had a particularly annoying security researcher bug me about a signed/unsigned integer check that could result in a target kernel panic with a malformed debug packet. Like you couldn't do the same by just writing random stuff at random addresses, since you are literally debugging the kernel with full memory access. Sad.
What I do is I add the following notice to my GitHub issue template: "X is a passion project and issues are triaged based on my personal availability. If you need immediate or ongoing support, then please purchase a support contract through my software company: [link to company webpage]".
Some open source projects which are well funded and/or motivated to grow are giddy with excitement at the prospect you might file a bug report [1,2]. Other projects will offer $250,000 bounties for top tier security bugs [3].
Other areas of society, like retail and food service, take an exceptionally apologetic, subservient attitude when customers report problems. Oh, sir, I'm terribly sorry your burger had pickles when you asked for no pickles. That must have made you so frustrated! I'll have the kitchen fix it right away, and of course I'll get your table some free desserts.
Some people therefore think doing a good job, as an open source maintainer, means emulating these attitudes. That you ought to be thankful for every bug report, and so very, very sorry to everyone who encounters a crash.
Needless to say, this isn't a sustainable way to run a one-person project, unless you're a masochist.
[1] https://llvm.org/docs/Contributing.html#id5 [2] https://dev.java/contribute/test/ [3] https://bughunters.google.com/about/rules/chrome-friends/574...
I think that's seriously over-estimating the quality of software in mainstream browsers and operating systems. Certainly some parts of mainstream OS's and browsers are very well written. Other parts, though...
Relevant XKCD: https://xkcd.com/2347/
There have been a lot of cases where something once deemed "unreachable" eventually was reachable, sometimes years later, after a refactoring and now there was an issue.
“Three.”
“Like, the number 3? As in, 1, 2, …?”
“Yes. If you’re expecting me to pick, this will be CVE-3.”
> Even if it is a valid security flaw, it is clear why it might rankle a maintainer. The report is not coming from a user of the project, and it comes with no attempt at a patch to fix the vulnerability. It is another demand on an unpaid maintainer's time so that, apparently, a security research company can brag about the discovery to promote its services.
> If Wellnhofer follows the script expected of a maintainer, he will spend hours fixing the bugs, corresponding with the researcher, and releasing a new version of libxml2. Sveshnikov and Positive Technologies will put another notch in their CVE belts, but what does Wellnhofer get out of the arrangement? Extra work, an unwanted CVE, and negligible real-world benefit for users of libxml2.
> So, rather than honoring embargoes and dealing with deadlines for security fixes, Wellnhofer would rather treat security issues like any other bug; the issues would be made public as soon as they were reported and fixed whenever maintainers had time. Wellnhofer also announced that he was stepping down as the libxslt maintainer and said it was unlikely that it would ever be maintained again. It was even more unlikely, he said, with security researchers ""breathing down the necks of volunteers.""
> [...] He agreed that ""wealthy corporations"" with a stake in libxml2 security issues should help by becoming maintainers. If not, ""then the consequence is security issues will surely reach the disclosure deadline (whatever it is set to) and become public before they are fixed"".
In the later case I'm wondering if there's an argument to be made for "Show me the code or shut up". Simply rejecting reports on security issue which are not also accompanied by a patch. I'm think, will it devalue the CVE on the researchers resume, if the project simply says no, on the grounds of not being a fix?
Probably not.
> ...there are currently four bugs marked with the security label in the libxml2 issue tracker. Three of those were opened on May 7 by Nikita Sveshnikov, a security researcher who works for a company called Positive Technologies.
FYI, Wiki tells me:
> Positive Technologies is a Russian information security research company and a global leader in cybersecurity.When it comes to fixing the issues, their customers will have to beg/spam/threaten the maintainers until the problem is solved. They probably won't write a patch; after all, Apple, Google, and Microsoft are only small companies with limited funds.
The point of my original post... that I hoped someone would see/interpret: Reporting "security bugs" without a patch or an offer to pay the lead maintainer to implement a fix feels like blackmail in 2025. Yes, I know this will be a hugely controversial opinion amoungst HN crowd. Personally: I don't see a huge amount of commercial value in pure infosec research that does not include funds to develop or fund a patch. The primary purpose of these "pure" infosec research firms is to generate FOMO for enterprise clients who pay them for private patches or "support".
The big point is this is a critical component for Apple and Google (and maybe Microsoft), and nobody is paying any attention to it.
Unhappy with a maintainer? Fork and maintain it yourself.
Some open source code creates issues in your project? Fix it and try to upstream. Upstream is not accepted? Fork and announce the fix.
Unpaid open source developers owe you nothing, you can't demand anything, their work is already a huge charitable contribution to humanity. If you can do better — fork button is universally available. Don't forget to say thank you to original authors while you stay on the shoulders of giants.
Yup. $10 000.
Remind me what the average Google salary is? Or how much profit Google made that year?
Or better still, what is the livable wage is where libxml maintainer lives? You know, the maintainer of the library used in the core Google Product?
What would a fair model look like? An open-source infrastructure endowment? Ongoing support contracts per critical library?
At the same time, I think there’s a tension in open source we don’t talk about enough: it’s built to be free and open to all, including the corporations we might wish were more generous. No one signed a contract!
As the article states, Libxml2 was widely promoted (and adopted) as the go-to XML parser. Now, the maintainer is understandably tired. There is now a sustainability problem that is more systemic than personal. How much did the creator of libxml benefit?
I don’t think we should expect companies to do the right thing just because they benefit and it isn’t how open source was meant to be and this isn’t how open source is supposed to work
But maybe that’s the real problem
https://www.statista.com/chart/25795/active-github-contribut...
"Microsoft is now the leading company for open source contributions on GitHub" (2016)
This is a garbage criticism. It’s perfectly adequate for that for almost everyone. If you are shipping it in a browser to billions of people, that’s a very unique situation, and any security issues are a you problem.
Not sure if this is intended to be a “show both sides” journalism thing but it’s a totally asshole throwaway comment.
The point is that libxml2 never had the quality to be used in mainstream browsers or operating systems to begin with. It all started when Apple made libxml2 a core component of all their OSes. Then Google followed suit and now even Microsoft is using libxml2 in their OS outside of Edge. This should have never happened. Originally it was kind of a growth hack, but now these companies make billions of profits and refuse to pay back their technical debt, either by switching to better solutions, developing their own or by trying to improve libxml2.
The behavior of these companies is irresponsible. Even if they claim otherwise, they don't care about the security and privacy of their users. They only try to fix symptoms.
Also the not so relevant security bugs are not just costs to the developers but the library churn is also costing more and more users if the user is forced by policy to follow in a timely manner the latest versions in the name of "security".
a) nonsense in which case nobody should spend any time fixing this (I'm thinking things like the frontend DDOS CVEs that are common) b) an actual problem in which case a compliance person at one of these mega tech companies will tell the engineers it needs to be fixed. If the maintainer refuses to be the person fixing it (a reasonable choice), the mega tech company will eventually just do it.
I suppose the risk is the mega tech company only fixes it for their internal fork.
They'd rather send a patch than having to maintain and sync an internal fork with upstream.
Thank you for reaching out to us. Please be aware that we do not run any kind of security bounty/reward programs.
Having performed our own analysis we have not been able to identify any practically exploitable security risks.
If you have found a practically exploitable security issue with our website, please provide some form of demonstration so that we may discuss further.
I don’t think that would come across as not being concerned about security, but puts the onus on the “researcher” to prove there is a real problem.
Chances are they did some automated scan and found some out of date JavaScript library version which despite having a vulnerability, is not actually a security risk on a static content site.
Of course that's exactly what traditional Linux distributions signed up to do.
Clearly many people have decided that they're better off without the distributions' packaging work. But maybe they should be thinking about how to get the "buffering" part back, and ideally make it work better than the distributions managed to.
"All null-pointer-referencing issues should come with an accompanying fix pull request".
I think something like "Null-pointer-referencing issues will not be looked at by core maintainers unless someone already provides a patch". That way, someone else who knows how to fix the problem can step in, and users aren't left with the false impression that merely reporting their bug will not guarantee a solution.
Yes open source has changed, from when the early 90s. There are more users, companies use projects and make millions with other peoples work.
I feel with the maintainer, with how ungrateful people are. And demanding without giving.
Open Source licenses fall short.
Open Source projects should clearly state what they think about fixing security, taking on external contributions or if they consider the project feature complete. Just like standard licenses, we should have a standard, parseable maintenance "contract".
"I fix whatever you pay for, I fix nothing, I fix how I see fit. Including disclosure, etc."
So everyone is clear about what to expect.
https://gitlab.gnome.org/GNOME/libxml2/-/blob/63f98ee8a3a11f...
"The viewpoint expressed by Wellnhofer's is understandable, though one might argue about the assertion that libxml2 was not of sufficient quality for mainstream use. It was certainly promoted on the project web site as a capable and portable toolkit for the purpose of parsing XML. Open-source proponents spent much of the late 1990s and early 2000s trying to entice companies to trust the quality of projects like libxml2, so it is hard to blame those companies now for believing it was suitable for mainstream use at the time."
If the license says one thing, and you say and promote something else, you can't say "But it's in the license" and "I said so at a conference" just as it fits you.
So what should I believe? What you write in the license? What you say at a conference? Nothing you say?
this is why i never report stuff to open source. if you wanna play bug bounty and cve hoarder its better to stick with bug bounty programs.
why? there the security researcher can be depressed about the process himself rather than some volunteer coder. gotta not make your issues other ppls issues.
Is the author being sarcastic? Or is that genuinely an immense sum relative to how little funding most FOSS gets?
Disastrous, apocalyptic consequences is the only way to get the attention of the real decision makers. If libxml2 just vanishes and someone explains to John Chrome or whoever that $150k a year will make the problem go away, it's a non-decision. $150k isn't even a rounding error on a rounding error for Google.
The only way to fight corporations just taking whatever they want is to absolutely wreck their shit when they misbehave.
Call it juvenile, sure, but corporations are not rational adults and usually behave like a child throwing a temper tantrum. There have to be real, painful and ongoing consequences in order to force a corporation to behave.
> The viewpoint expressed by Wellnhofer's is understandable, though one might argue about the assertion that libxml2 was not of sufficient quality for mainstream use. It was certainly promoted on the project web site as a capable and portable toolkit for the purpose of parsing XML. Open-source proponents spent much of the late 1990s and early 2000s trying to entice companies to trust the quality of projects like libxml2, so it is hard to blame those companies now for believing it was suitable for mainstream use at the time.
I think it's very obvious that the maintainer is sick of this project on every level, but the efforts to trash talk its quality and the contributions of all previous developers doesn't sit right with me.
This is yet another case where I fully endorse a maintainer's right to reject requests and even step away from their project, but in my opinion it would have been better to just make an announcement about stepping away than to go down the path of trash talking the project on the way out.
(Disclosure: I'm a past collaborator with Nick on other projects. He's a fantastic engineer and a responsible and kind person.)
There is plenty of software today that is tested within cost and schedule that’s closed source and it’s running in production. I get the point but libxml is not one of those cases
That's reasonable, being a maintainer is a thankless job.
However i think there is a duty to step aside when that happens. If nobody can take the maintainer's place, then so be it, its still better than the alternative. Being burned out but continuing anyways just hurts everyone.
Its absolutely not the security researcher's fault for reporting real albeit low severity bugs (to be clear though, entirely reasonable for maintainers to treat low severity security bugs as public. The security policy is the maintainer's decision, its not right to blame researchers for following the policy maintainers set)