A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or nude selfies being spread all over the internet.
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.
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.
bastawhiz 10 minutes ago [-]
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.
ivanjermakov 32 minutes ago [-]
DoSing autonomous vehicle brake controls...
bastawhiz 9 minutes ago [-]
I hope my brakes aren't parsing xml
icedchai 2 hours ago [-]
Everything is a "security bug" in the right (wrong?) context, I suppose.
cogman10 2 hours ago [-]
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.
nicce 3 hours ago [-]
> A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or nude selfies being spread all over the internet.
That is not true at all. Availability is also critical. If nobody can use bank accounts, bank has no purpose.
arp242 2 hours ago [-]
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.
nicce 2 hours ago [-]
> 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.
I wouldn't personally classify these as denial of service. They are just bugs. 500 status code does not mean that server uses more resources to process it than it typically does. OOMing your browser has no impact to others. These should be labeled correctly instead of downplaying the significance of denial of service.
Like I said in my other comment, there are two entities - the end-user and the service provider. The service provider/business loses money too when customers cannot make transactions (maybe they had promise to keep specific uptime and now they need to pay compensations). Or they simple get bankrupted because they lost their users.
Even customers may lose money or something else when they can't make transactions. Or maybe identification is based on bank credentials on some other service. The list goes on.
bogeholm 2 hours ago [-]
Security and utility are separate qualities.
You’re correct that inaccessible money are useless, however one could make the case that they’re secure.
burnt-resistor 24 minutes ago [-]
Define what you mean by "security".
Control integrity, nonrepudiation, confidentiality, privacy, ...
Also, define what you mean by "utility" because there's inability to convert a Word document, inability to stop a water treatment plant from poisoning people, and ability to stop a fire requiring "utility".
nicce 2 hours ago [-]
I think you are only considering the users - for the business provider the availability has larger meaning because the lack of it can bankrupt your business. It is about securing operations.
arp242 2 hours ago [-]
If a panic or null pointer deref in some library causes your entire business to go down long enough that you go bankrupt, then you probably deserve to go out of business because your software is junk.
nicce 2 hours ago [-]
I believe you know well that bankrupt is the worst case. Many business functions can be so critical that 24h disturbance is enough to cause high financial damages or even loss of life. A bug in the car's brakes that prevents their usage is also denial of service.
arp242 1 hours ago [-]
Or 24h disturbance. Or indeed taking the entire system down at all.
And no one is talking about safety-critical systems. You are moving the goalposts. Does a gas pedal use a markdown or XML parser? No.
nicce 33 minutes ago [-]
The point was about the importance of availability.
> Does a gas pedal use a markdown or XML parser? No.
not paying rent can get you evicted. and not paying your medical bill can get you denied care. (in china most medical care is not very expensive, but every procedure has to be paid in advance. you probably won't be denied emergency care so your life would not be in immediate danger, but sometimes an optional scan discovers something life threatening that you weren't aware of so not being able to pay for it can put you at risk)
leni536 2 hours ago [-]
Virtually all bugs have some cost. Security bugs tend to be more expensive than others, but it doesn't mean that all very expensive bugs are security bugs.
Inability for drug dispensers to dispense life saving drugs due to DoS has failed utility and will cost lives, would you describe that as secure?
p1necone 56 minutes ago [-]
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.
antonymoose 2 hours ago [-]
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.
nicce 2 hours ago [-]
This depends on the context to be fair. Front-end DoS can suddenly expand into botnet DDoS if you can trigger it by just serving a specific kind of URL. E.g. search goes into endless loop that makes requests into the backend.
Onavo 2 hours ago [-]
Until the same library for their "isomorphic" backend..
hsbauauvhabzb 54 minutes ago [-]
Server side rendering is all the rage again, so yeah it might be.
kibwen 3 hours ago [-]
> Ariadne Conill, a long-time open-source contributor, observed that corporations using open source had responded with ""regulatory capture of the commons"" instead of contributing to the software they depend on.
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.
xxpor 3 hours ago [-]
Why bother open sourcing if you're not interested in getting people to use it?
OkayPhysicist 2 hours ago [-]
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.
SpicyLemonZest 48 minutes ago [-]
The GPL "does not prohibit anyone" in a narrow legalistic sense. In colloquial discussions (see e.g. https://www.gnu.org/licenses/why-not-lgpl.en.html), the Free Software Foundation is quite clear that the GPL exists to stop proprietary software developers from using your code by imposing conditions they can't satisfy.
charcircuit 1 hours ago [-]
GPL doesn't force people to share their fixes and improvements. And there is nothing bad faith about not sharing all your hardwork for free.
OkayPhysicist 52 minutes ago [-]
It does if you then share the resulting software. And I think if you make an improvement just for your own enjoyment, you'd be a better person if you shared it back than if you didn't.
ben0x539 1 hours ago [-]
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!
gizmo686 2 hours ago [-]
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.
OkayPhysicist 2 hours ago [-]
We have a solution to this. It's called the (L)GPL. If people would stop acting like asking for basic (zero cost) decency in exchange for their gift is tantamount to armed robbery, we could avoid this whole mess.
bigfatkitten 3 hours ago [-]
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.
meindnoch 2 hours ago [-]
Trillion dollar corporations are not "people".
eikenberry 24 minutes ago [-]
No corporations are people, they are legal constructs. How much money they are worth makes no difference.
freeone3000 1 hours ago [-]
What’s the point in people using it if all that profit ends up in someone else’s pockets?
lelandbatey 2 hours ago [-]
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.
itsanaccount 3 hours ago [-]
you seem to have mistaken corporations for people.
kortilla 3 hours ago [-]
You seem to think corporations aren’t made of people
dsr_ 2 hours ago [-]
Sheds are made of wood, but they aren't trees.
eikenberry 21 minutes ago [-]
Groups of people are not the same as the people that make them up. They think differently and have different motivations.
djoldman 2 hours ago [-]
I really don’t understand solo unpaid maintainers who feel “pressure” from users. My response would always be: it’s my repo, my code, if you don’t like how I’m doing things, fork the code megashrug.
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!
kayodelycaon 2 hours ago [-]
Your solution is exactly right, but let me try to help understanding the problem.
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.”
michaelt 1 hours ago [-]
> I really don’t understand solo unpaid maintainers who feel “pressure” from users.
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.
The correct response to this kind of thing is an invoice IMO.
zppln 3 hours ago [-]
Very sad read. Much of the multi-billion dollar project I work on is built on top of libxml2 and my company doesn't have a clue. Fuck, even most of my colleagues working with XML every day don't even know it because they only interface indirectly with it via lxml.
burnt-resistor 22 minutes ago [-]
Well, they need to pony up around $150k or so to keep it alive rather than freeloading off the work of others.
mschuster91 3 hours ago [-]
> Fuck, even most of my colleagues working with XML every day don't even know it because they only interface indirectly with it via lxml.
> The point is that libxml2 never had the quality to be used in mainstream browsers or operating systems to begin with
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...
burnt-resistor 20 minutes ago [-]
That's the problem of abusing and freeloading off critical components of the FOSS supply chain. Megacorps must pay their fair share or bad things happen, just like unbounded, corrupt crapitalism.
JonChesterfield 2 hours ago [-]
This is an alarming read. Not so much the "security bugs are bugs, go away" sentiment which seems completely legitimate, but that libxml2 and libxslt have been ~ solo dev passion projects. These aren't toys. They're part of the infrastructure computing is built on.
SAI_Peregrinus 21 minutes ago [-]
There are two types of responsible disclosure: coordinated disclosure where there's an embargo (ostensibly so that the maintainer can patch the software before the vulnerability is widely known) and full disclosure where there's no embargo (so that users can mitigate the vulnerability on their own, useful if it's already being exploited). There's no reason a maintainer shouldn't be allowed to default to full disclosure. In general, any involved party can disclose fully. Irresponsible disclosure is solely disclosing the vulnerability to groups that will exploit it, e.g. NSO.
DeepYogurt 3 hours ago [-]
It'd be great if some of these open source security initiatives could dial up the quality of reports. I've seen so so many reports for some totally unreachable code and get a cve for causing a crash. Maintainers will argue that user input is filtered elsewhere and the "vuln" isn't real, but mitre don't care.
selfhoster11 2 hours ago [-]
Better yet - they could contribute a patch that fixes the issue.
2 hours ago [-]
mschuster91 3 hours ago [-]
> I've seen so so many reports for some totally unreachable code and get a cve for causing a crash.
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.
DeepYogurt 3 hours ago [-]
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.
bigfatkitten 3 hours ago [-]
“PoC or GTFO” is an entirely reasonable response.
duped 1 hours ago [-]
"PR or payment to fix or GTFO" is also a reasonable response
marcusb 2 hours ago [-]
Also a wonderful zine!
mschuster91 2 hours ago [-]
IMHO, at least the foundations of what makes the Internet tick - the Linux kernel, but also stuff like SSL libraries, format parsers, virtualization tooling and the standard libraries and tools that come installed by default on Linux systems - should be funded by taxpayers. The EU budget for farm subsidies is about 40 billion euros a year - cut 1% off of it, so 400 million euros, and invest it into the core of open source software, and we'd get an untold amount of progress in return.
charcircuit 1 hours ago [-]
It's not the government's job to subsidize people's bad business models.
kstrauser 2 hours ago [-]
> It includes a request for Wellnhofer to provide a CVE number for the vulnerability and provide information about an expected patch date.
“Three.”
“Like, the number 3? As in, 1, 2, …?”
“Yes. If you’re expecting me to pick, this will be CVE-3.”
firesteelrain 1 hours ago [-]
Understand the stance, but the big corps using it (Apple, Google, Microsoft) are using it and acknowledge it silently at risk. It's not entirely fair though, Google did make a donation.
burnt-resistor 17 minutes ago [-]
Like tipping someone a penny. If it's so critical to their business, then they can pay a pittance to sustain it.
Aurornis 3 hours ago [-]
I empathize with some of the frustrations, but I'm puzzled by the attempts to paint the library as low-quality and not suitable for production use:
> 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.
rectang 2 hours ago [-]
I think Wellnhofer is accurate in his assessment of the current state of the library and its support infrastructure institutions. Software without adequate ongoing maintenance should not be used in production.
(Disclosure: I'm a past collaborator with Nick on other projects. He's a fantastic engineer and a responsible and kind person.)
flomo 2 hours ago [-]
Recall similar things were said about OpenSSL, and it was effective at getting corps to start funding the project.
wbl 2 hours ago [-]
It was not however effective at getting the project to care about quality or performance.
tptacek 2 hours ago [-]
I don't think this trend much matters. Serious vendors concerned about security will simply vendor things like libxml2 and handle security inbounds themselves; they'll become the real upstreams.
benced 2 hours ago [-]
Do we need a more profound solution than what the maintainer is doing here? Any given bug is either:
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.
2 hours ago [-]
bjourne 2 hours ago [-]
So software released under the MIT license and maintainer now complains that corporate users are not helping improve it? I'd file this under Stallman told you so.
kayodelycaon 2 hours ago [-]
No. He’s complaining about companies demanding he do free work for them.
burnt-resistor 15 minutes ago [-]
The correct response is "FU, pay me."
Rendered at 00:45:20 GMT+0000 (Coordinated Universal Time) with Vercel.
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...
[2]: https://rustsec.org/advisories/RUSTSEC-2024-0373.html
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.
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.
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.
I wouldn't personally classify these as denial of service. They are just bugs. 500 status code does not mean that server uses more resources to process it than it typically does. OOMing your browser has no impact to others. These should be labeled correctly instead of downplaying the significance of denial of service.
Like I said in my other comment, there are two entities - the end-user and the service provider. The service provider/business loses money too when customers cannot make transactions (maybe they had promise to keep specific uptime and now they need to pay compensations). Or they simple get bankrupted because they lost their users.
Even customers may lose money or something else when they can't make transactions. Or maybe identification is based on bank credentials on some other service. The list goes on.
You’re correct that inaccessible money are useless, however one could make the case that they’re secure.
Control integrity, nonrepudiation, confidentiality, privacy, ...
Also, define what you mean by "utility" because there's inability to convert a Word document, inability to stop a water treatment plant from poisoning people, and ability to stop a fire requiring "utility".
And no one is talking about safety-critical systems. You are moving the goalposts. Does a gas pedal use a markdown or XML parser? No.
> Does a gas pedal use a markdown or XML parser? No.
Cars in general use, extensively: https://en.wikipedia.org/wiki/AUTOSAR
If a hacker wants to DoS their own browser I’m fine with that.
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.
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 don’t think many projects see acquiring unpaying corporate customers as a goal.
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.
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.”
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...
Relevant XKCD: https://xkcd.com/2347/
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...
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.”
> 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.)
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.