@davidnjoku @Andres4NY

It isn't. Because of recent events with #libxml2, the discussion has arisen once again, in the open source world, of how much businesses who rely upon projects that are both gratis and libre are freeloading off volunteers, and dressing doing so up in security theatre. Security theatre that holds within it a threat against the livelihoods of those volunteers.

And in addition to that there are the businesses whose own livelihoods are built around desperately finding as many things to classify as security problems as they can, to gain a reputation as a problem finder, without lifting a finger to fix any of them in any way. Because no-one is apparently checking their reputations as problem fixers.

* https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/

#OpenSource #FreeSoftware

Libxml2 proudly parades its "no #security embargoes" policy like a badge of honor, because who needs secrecy when #hackers can have a head start? 🚀 In classic open-source fashion, it's a shining example of #innovation and #chaos, proving once again that security is just a state of mind, right? 🔓✨
https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/ #Libxml2 #open #source #transparency #HackerNews #ngated

Libxml2's "no security embargoes" policy

https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/

#HackerNews #Libxml2 #no #security #embargoes #policy #security #libxml2 #open-source #software #development #cybersecurity

About #Libxml2 usage in core products (macos, chrome, windows...) "The point is that libxml2 never had the quality to be used in mainstream browsers or operating systems to begin with. [...]. 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." https://gitlab.gnome.org/GNOME/libxml2/-/issues/913#note_2439345

The lone volunteer maintainer of #libxml2, one of the open source ecosystem’s most widely used XML parsing libraries, with an excellent rant about how Apple, Google, Microsoft and their BigTech Bros exploit #opensource software and the volunteers behind it:

https://gitlab.gnome.org/GNOME/libxml2/-/issues/913#note_2439345

libxml2 Maintainer Ends Embargoed Vulnerability Reports, Citing Unsustainable Burden

The lone volunteer maintainer of libxml2, one of the open source ecosystem’s most widely used XML parsing libraries, has announced a policy shift that drops support for embargoed security vulnerability reports.

I've taken heat in other venues for talking about this kind of thing when there's been an overreaction to a near miss caused by overreliance on a project that isn't getting support from the organizations that rely on it.

There's not one here yet. Maybe big tech can pay attention this time?

#libxml2

What are we (NRENs deploying SAML) gonna do about libxml2? It is now sort of unmaintained and reading the announcement for it, I can totally understand why the maintainer wants to step away.

https://gitlab.gnome.org/GNOME/libxml2/-/issues/913

#saml #nren #xml #libxml #libxml2 #refeds

Went looking for why FreeBSD #libxml2 isn't fixed yet and hooooo boy... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279705

I really don't like to push package updates with known vulnerabilities but this one doesn't look like it's going to be resolved any time soon.

#libxml2 2.14.1 has been released (#Xmlsoft / #libxml / #XML / #ExtensibleMarkupLanguage / #CVE / #SecurityVulnerability) https://github.com/GNOME/libxml2

CVE-2024-40896 Analysis: libxml2 XXE due to type confusion

https://www.openwall.com/lists/oss-security/2024/12/25/2

#cve #linux #libxml2 #xxe #vulnerability #exploitation #bug #typeconfusion

CVE-2024-40896 Analysis: libxml2 XXE due to type confusion

https://www.openwall.com/lists/oss-security/2024/12/25/2

#cve #linux #libxml2 #xxe #vulnerability #exploitation #bug #typeconfusion

I tried validating #Docbook v5 using #xmllint from #libxml2 via #RelaxNG and #Schematron but wasn't successful. The RNG validation threw unexpected errors and the Schematron validation threw an internal error. It could be my source file, but it seems fine. Does somebody here have a working setup or tips to share?

At $DAYJOB, we have an admin #Rails app and one feature is displaying a large block of text to the user, akin to a log file. We run that through the `sanitize` helper in the view for safety. Yesterday I learned that the #libxml2 library used by #nokogiri has a soft-limit of ten million characters per text node. In this environment, excess text gets silently truncated. You can go higher, but the Rails/Loofah #api doesn't support that.

#ruby #rubyonrails #webdevelopment #programming

Is it me or is there no way to prevent #xmllint from loading external #XML entities in an XML document? I’ve been trying to find a command-line switch to disable that entirely but to no avail. There’s the --nonet option, but it only disables remote XML entity loading and I can still include /etc/passwd in my output.

Does it mean that any program calling the xmllint utility from #libxml2 (e.g. a shell script) is vulnerable to XML external entity injection?

#security

#libxml2 2.12 #broke the library for existing C++ apps: "To prepare for future improvements, some API functions now expect or return a const xmlError struct."

error: invalid conversion from 'void (*)(void*, xmlError*)' {aka 'void (*)(void*, _xmlError*)'} to 'xmlStructuredErrorFunc' {aka 'void (*)(void*, const _xmlError*)'}

🤦‍♂️

I found at least one spot where there is work towards my #libxml2 for #Dlang efforts. It is right next to some #ATS code for parsing s-expressions. :) (I might still use that instead of either JSON or libguile, now that I have found it.)

Hmm. Maybe I should attempt to make an automatically generated interface from #ATS to #libguile, as I did for an interface from #Dlang to #libxml2. (The latter is sitting somewhere in my ‘chemoelectric’ repository. It is constructed mostly by Awk scripts. But I’ll probably use Object Icon instead, this time.)

I never thaught I'd be saying this, but processing #XML from #C to turn #XHTML into #SSML with #libxml2 was an utterly *enjoyable* experience! I know right, in what universe is that possible? But props go to Daniel Veillard, Gnome, and contributors. It's fast, simple, and easy to understand, and everything just worked!

It seems that the fact that #Apple has released an emergency patch for two #libxml2 vulnerabilities in #macOS 13.0.1, but no corresponding updates for Monterey or Big Sur, got some people thinking that those systems are not vulnerable. l think that conclusion is wrong!

The update was very fast on Ventura due to Rapid Security Response [edit: not Rapid Security Response, just the improvements to update speed in Ventura]. These patches would have taken a lot longer to install on Monterey or Big Sur, so maybe Apple doesn’t think that weighs up against the risk of these vulnerabilities. Apple probably has a different bar for what requires a security patch with this feature.

Secondly, Apple has officially stated that not all vulnerabilities get fixed in older macOS versions due to architectural differences. While I’m sure they’ll eventually patch these, that does make it clear that you need to be on the latest OS to get all patches as soon as possible.

#Ventura #RapidSecurityResponse #vulnerability

CVE-2022-40303 and CVE-2022-40304 just got patched in iOS 16.1.1 that affected #libxml2

Remember to update :)