[HN Gopher] Libxml2's "no security embargoes" policy
___________________________________________________________________
Libxml2's "no security embargoes" policy
Author : jwilk
Score : 75 points
Date : 2025-06-25 19:36 UTC (3 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| zppln wrote:
| 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.
| mschuster91 wrote:
| > 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.
|
| Relevant XKCD: https://xkcd.com/2347/
| DeepYogurt wrote:
| 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.
| mschuster91 wrote:
| > 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 wrote:
| 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 wrote:
| "PoC or GTFO" is an entirely reasonable response.
| marcusb wrote:
| Also a wonderful zine!
| mschuster91 wrote:
| 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.
| selfhoster11 wrote:
| Better yet - they could contribute a patch that fixes the
| issue.
| kibwen wrote:
| _> 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 wrote:
| Why bother open sourcing if you're not interested in getting
| people to use it?
| itsanaccount wrote:
| you seem to have mistaken corporations for people.
| kortilla wrote:
| You seem to think corporations aren't made of people
| dsr_ wrote:
| Sheds are made of wood, but they aren't trees.
| bigfatkitten wrote:
| 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 wrote:
| Trillion dollar corporations are not "people".
| gizmo686 wrote:
| 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 wrote:
| 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.
| lelandbatey wrote:
| 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.
| OkayPhysicist wrote:
| 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.
| arp242 wrote:
| 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.
|
| [1]:
| https://github.com/gomarkdown/markdown/security/advisories/G...
|
| [2]: https://rustsec.org/advisories/RUSTSEC-2024-0373.html
| nicce wrote:
| > 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.
| bogeholm wrote:
| Security and utility are separate qualities.
|
| You're correct that inaccessible money are useless, however
| one could make the case that they're secure.
| nicce wrote:
| 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.
| leni536 wrote:
| 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.
| em-bee wrote:
| 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)
| arp242 wrote:
| 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.
| marcusb wrote:
| https://www.sentinelone.com/cybersecurity-101/cybersecurity
| /...
| antonymoose wrote:
| 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.
| Onavo wrote:
| Until the same library for their "isomorphic" backend..
| nicce wrote:
| 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.
| arp242 wrote:
| 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.
| icedchai wrote:
| Everything is a "security bug" in the right (wrong?) context, I
| suppose.
| cogman10 wrote:
| 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.
| Aurornis wrote:
| 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 wrote:
| 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 wrote:
| Recall similar things were said about OpenSSL, and it was
| effective at getting corps to start funding the project.
| bjourne wrote:
| 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.
| JonChesterfield wrote:
| 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.
| bryanlarsen wrote:
| > 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...
| kstrauser wrote:
| > 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."
| tptacek wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-25 23:00 UTC)