Re: libxml2 author overwhelmed with security requests

On Mon, Jul 21, 2025 at 12:46:03PM +0530, Sandeep Thakkar wrote:
> 
> On Fri, Jun 20, 2025 at 2:42 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
>     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.
> 
> Also, libxslt depends on libxml2, and there is no maintainer now after the
> recent commits done to remove the existing ones:
> https://gitlab.gnome.org/GNOME/libxslt/-/commit/
> c8b1ea4b89a9b81fa611f32c80f47df0c3b3b004
> https://gitlab.gnome.org/GNOME/libxslt/-/commit/
> 923903c59d668af42e3144bc623c9190a0f65988

Where do we think our use of libxml2 is heading?  Do you suspect
security scanners will start negative reporting the use of libxml2?

-- 
  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.