Libxml2's "no security embargoes" policy [LWN subscriber-only content]
Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!
Libxml2, an XML parser and toolkit, is an almost perfect example of the successes and failures of the open-source movement. In the 25 years since its first release, it has been widely adopted by open-source projects, for use in commercial software, and for government use. It also illustrates that while many organizations love using open-source software, far fewer have yet to see value in helping to sustain it. That has led libxml2's current maintainer to reject security embargoes and sparked a discussion about maintenance terms for free and open-source projects.
A short libxml2 history
The original libxml, also known as gnome-xml, was written by Daniel Veillard for the GNOME project. He also developed its successor, libxml2, which was released in early 2000 under the MIT license, even though GNOME applications tended to be under the GPLv2.
In the early 2000s, Veillard seemed eager to have others adopt libxml2 outside the GNOME project. It was originally hosted on its own site rather than on GNOME infrastructure. Libxml2 is written in C, but had language bindings for C++, Java, Pascal, Perl, PHP, Python, Ruby, and more. The landing page listed a slew of standards implemented by libxml2, as well as the variety of operating systems that it supported, and boasted that it " passed all 1800+ tests from the OASIS XML Tests Suite ". The "reporting bugs and getting help" page gave extensive guidance on how to report bugs, and also noted that Veillard would attend to bugs or missing features " in a timely fashion ". The page, captured by the Internet Archive in 2004, makes no mention of handling security reports differently than bug reports—but those were simpler times.
One can see why organizations felt comfortable, and even encouraged, to adopt libxml2 for their software. Why reinvent the extremely complicated wheel when someone else has not only done it but also bragged about their wheel's suitability for purpose and given it a permissive license to boot?
By the late 2000s, the project had matured, and the pace of releases slowed accordingly. Veillard continued to maintain the project, but skimming through the GNOME xml mailing list shows that his attention was largely elsewhere. Nick Wellnhofer began to make regular contributions to the project around 2013, and by 2017 he was doing a great deal of work on the project, eventually doing most of the work on releases—though Veillard was still officially sending them out. He was also making similar contributions to a related project, libxslt, which is a processor for Extensible Stylesheet Language Transformations (XSLT) which are used for transforming XML documents into other XML documents or into HTML, plain text, etc.
I want my libxml2
In April 2021, Stefan Behnel complained that it had been almost 18 months since the last libxml2 release. " There have been a lot of fixes during that time, so, may I kindly ask what's hindering a new release? " Veillard replied that the reason was that he was too busy with work, and there was " something I would need to get in before a release ". That something seems to be a security fix for CVE-2021-3541, a flaw in libxml2 that could lead to a denial of service. The release of libxml2 2.9.11, which fixed the CVE, and 2.9.12, seem to have been the last contributions from Veillard to the project.
Wellnhofer had become the de facto maintainer of libxml2 and libxslt as Veillard was fading away from them, but he temporarily stepped down in July 2021. He had been able to fund his work through Chrome bug bounties and other Google programs, but: " returns from security research are diminishing quickly and I see no way to obtain a minimal level of funding anymore ".
Veillard thanked Wellnhofer for his work, and said he was not sure that he would be able to ensure the same level of care for the projects on his own: " that's obvious for anybody monitoring those lists lately ".
In January 2022, Wellnhofer announced that he was able to resume maintenance of libxml2 and libxslt through 2022, thanks to a donation from Google. He planned to move the projects to GNOME's infrastructure and resume releases, plus set up an official way to sponsor libxml2 development. Ultimately, he chose Open Source Collective as a fiscal host. (LWN covered Open Source Collective in 2024.) To date, it appears that the project has received the immense sum of $11,000, most of which was in the form of a $10,000 donation from Google, which appears to be the funding Wellnhofer received for maintenance of libxml2 through 2022.
Irresponsible behavior
Fast-forwarding to 2025, Wellnhofer opened an issue on May 8, in the libxml2 GitLab repository to announce a new security policy for the project. He said that he was spending several hours each week dealing with security issues, and that was unsustainable for an unpaid volunteer.
As an example of what Wellnhofer was faced with, and a hint as to what may have been the final straw, 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. One of the issues is a report about a null-pointer deference that could lead to a denial of service. It includes a request for Wellnhofer to provide a CVE number for the vulnerability and provide information about an expected patch date. Note that neither libxml2 nor GNOME are CVE Numbering Authorities (CNAs).
One can debate whether the vulnerabilities reported by Sveshnikov and other researchers have much value. Wellnhofer argues he has fixed about 100 similar bugs and does not consider that class of bugs to be security-critical. 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. "
Treating security flaws as regular bugs might make some downstream users nervous, but Wellnhofer hopes it will encourage more contributions:
The more I think about it, the more I realize that this is the only way forward. I've been doing this long enough to know that most of the secrecy around security issues is just theater. All the "best practices" like OpenSSF Scorecards are just an attempt by big tech companies to guilt trip OSS maintainers and make them work for free.
GNOME contributor Michael Catanzaro worried that security flaws would be exploited in the wild if they were treated like regular bugs, and suggested alternate strategies for Wellnhofer if he was burning out. 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 ".
Wellnhofer was not interested in finding ways to put a band-aid on the problem; he said that it would be better for the health of the project if companies stopped using it altogether:
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.
He added that he would love to mentor new maintainers for libxml2, " but there simply aren't any candidates ".
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.
However, Wellnhofer's point that these companies have not looked to improve or care for libxml2 in the intervening years is entirely valid. It seems to be a case of "out of sight, out of mind"; as long as there are no known CVEs plaguing the many open-source libraries that these applications depend on, nobody at Apple, Google, Microsoft, or any of the other companies, seem to care much about the upkeep of these projects. When a vulnerability is found, the maintainer is seemingly expected to spring into action out of a sense of responsibility to the larger ecosystem.
Safe to say no
Wellnhofer's arguments about corporate behavior have struck a chord with several people in the open-source community. 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.
She suggested that maintainers lacked the " psychological safety " to easily say no. They can say no to corporate requests; doing so, however, means weighing that " the cost of doing so may negatively impact the project's ability to meet its end goal ". In that light, maintainers may opt to concede to requests for free labor rather than risking the unknown consequences.
In response to Wellnhofer's change in security policy for libxml2, Mike Hoye proposed that projects adopt public maintenance terms that would indicate " access to code is no promise of access to people ". The terms for a project would be included as a MAINTENANCE-TERMS.md file in the top-level directory, similar to the README.md and CONTRIBUTING.md files included with many projects these days. The sample maintenance terms that Hoye provided state that the software is provided as-is and disclaim any promises, including response time, disclosure schedules, or any " non-contractual obligations or conventions, regardless of their presumed urgency or severity ".
Hoye said that the point of the maintenance terms is to deliberately build a culture of social permission where maintainers feel safe saying "no". Otherwise, he said:
Someday, somebody's going to come to you and say, I'm from Apple, I'm from Amazon, I'm from Project Zero and you need to drop everything because your project is the new heartbleed or Log4j or who knows what and the world is falling over and if that psychological offramp isn't there, if you haven't laid out clearly what PROVIDED AS-IS means and how you're going to act about it ahead of time, saying "I'll be at my kid's recital" or "I'm on vacation" or just "no" is extremely difficult.
Chris Siebenmann said that he thinks that Wellnhofer's rejection of security embargoes is " an early sign of more of this to come, as more open source maintainers revolt ". The current situation, Siebenmann said, is increasingly bad for the maintainers involved and is not sustainable. He now draws a sharp distinction between the corporate use of open-source software versus independent projects, such as Debian or the BSDs, run by volunteers; he expects that others will be doing the same in the future.
Maintainers may not want to say no to other volunteers. But, Siebenmann said, if a corporation shows up with a security issue, they can point to the maintenance terms—because corporations are not using open source as part of a cooperative venture and are not people " even if they employ people who make 'people open source' noises ".
Wellnhofer's stance and Hoye's idea seem to be resonating with other maintainers who have strong feelings about corporate open-source behavior. Whether open-source maintainers adopt MAINTENANCE-TERMS.md files as a common practice is yet to be seen. The increasing frequency of conversations about funding open source and whether corporations are doing their share does suggest that something needs to change soon if open source is to be sustainable and not just a sucker's game for maintainers.
to post comments