Обсуждение: libxml2 author overwhelmed with security requests

This blog post explains the serious problems the single libxml2 author
is having in maintaining the library:

    https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports

There are few learnings from this:

*  libxml2 is even less production-ready than we thought
*  many projects don't have the resources we do

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

On 19.06.25 03:41, Bruce Momjian wrote:
> This blog post explains the serious problems the single libxml2 author
> is having in maintaining the library:
> 
>     https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports
> 
> There are few learnings from this:
> 
> *  libxml2 is even less production-ready than we thought
> *  many projects don't have the resources we do
> 

That's even worse than I thought. Especially this disclaimer consideration:

“This is open-source software written by hobbyists, maintained by a
single volunteer, badly tested, written in a memory-unsafe language and
full of security bugs. It is foolish to use this software to process
untrusted data.”

No wonder other major databases opt for writing their own XML processing
engines. Sadly, despite these issues, there doesn't seem to be a decent
alternative to libxml2 :(

-- 
Jim

On Thu, Jun 19, 2025 at 09:24:32PM +0200, Jim Jones wrote:
> On 19.06.25 03:41, Bruce Momjian wrote:
> > This blog post explains the serious problems the single libxml2 author
> > is having in maintaining the library:
> > 
> >     https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports
> > 
> > There are few learnings from this:
> > 
> > *  libxml2 is even less production-ready than we thought
> > *  many projects don't have the resources we do
> > 
> 
> That's even worse than I thought. Especially this disclaimer consideration:
> 
> “This is open-source software written by hobbyists, maintained by a
> single volunteer, badly tested, written in a memory-unsafe language and
> full of security bugs. It is foolish to use this software to process
> untrusted data.”
> 
> No wonder other major databases opt for writing their own XML processing
> engines. Sadly, despite these issues, there doesn't seem to be a decent
> alternative to libxml2 :(

I think our solution to making Postgres more secure would be to just
remove XML support --- we aleady have the inclusion of libxml options at
configure time.  I don't think there is community support to be
developing an XML library --- some Postgres companies might feel
differently, but that is not the community's concern.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Pavel Stehule <pavel.stehule@gmail.com> writes:
> Own implementation of SQL/XML generating functions like XMLFOREST or
> XMLELEMENT should not be too
> difficult. Significantly more difficult problem is parsing of XML (more
> with namespaces), although some basic
> support for XMLTABLE should not be too hard too.

I don't think anybody really wants to roll our own XML parser.

> Isn't possible to call Rust code from C? Then maybe there are some
> possibility from Rust world
> https://github.com/ballsteve/xrust

Maybe.  I think the fundamental problem here, similar to what we've
run into elsewhere, is that we chose a library to depend on without
thinking hard enough about whether it would be well-supported in the
long run.  I see little reason to think that that risk would be less
for some random not-written-in-C implementation.  If we want to
jump ship away from libxml2, we had better ask hard questions about
the new choice.

            regards, tom lane