Обсуждение: 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.

Bruce Momjian <bruce@momjian.us> writes:
> Where do we think our use of libxml2 is heading?  Do you suspect
> security scanners will start negative reporting the use of libxml2?

There's at least one distro that's already stopped building with
--with-libxml out of security concerns.  (I forget who exactly,
but it's been mentioned on the PG lists.)

            regards, tom lane

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

After reading this thread I've stepped in to maintain libxslt and me and other

Mexican developers are going to be on top of libxml2. We use this libraries and their

Rust bindings because we're writing libraries for handling Mexican taxes and they are

wrapped in XML.

So at least me and another developer will be helping with this libraries and will make

our best effort to keep them up to date both in securities and functionalities (eg. XSLT 2.0 support).

Cheers,

Iván