Make libxml2 the default

[Dave-Allured]

Version: Current development branch "main", pre-4.8.2
Platform: All
OS: All

Please make libxml2 the default in preference to ezxml. Libxml2 capability was recently added in PR #2139, but the older ezxml is selected by default, unless libxml2 is explicitly enabled.

Pros and cons are well reviewed in #2119 and #2133. For me, the most significant factors are that libxml2 is in current maintenance and monitored by many eyes for security issues. I am trying to not rehash all the previous arguments.

Ezxml in the Dec. 20 netcdf-c snapshot failed for me on Mac OS 10.15.7 Catalina and Apple clang version 12.0.0, due to #2146 (implicit declarations). With --enable-libxml2, it worked like a charm.

[Dave-Allured]

It seems that libxml2 is falling away from current maintenance.
https://gitlab.gnome.org/GNOME/libxml2/-/issues/319

With that in combination with package size and dependencies, I am now leaning toward preferring tinyxml2 as the netcdf default parser, rather than libxml2. I would appreciate insights on this choice from others more familiar with the XML ecology. However, please do retain --enable-libxml2 as an option.

Thanks @DennisHeimbigner for already replacing the old bundled ezxml with bundled tinyxml2 (#2170).

[DennisHeimbigner]

I am surprised about libxml2; I thought it was the sine qua non of xml parsers.
Perhaps it has become too large and users (like me) prefer smaller footprint libraries.
Oh well, thanks for the heads up about this.

[dopplershift]

Well, just because it's the most important doesn't mean the project has a lot of maintainers and support. See openssl, log4j, etc...

[Dave-Allured]

I might have got the wrong impression. I was disappointed to find a maintainer problem in libxml2 recent history.

Anyway, the most important thing is to have two modern alternatives within netcdf-c. We have that now, thanks to Dennis's diligence. The choice of which one should be default, is not critical.

[e4t]

Yes, this is definitely bad. However, it seems the Gnome community is aware of this and it is discussed - I'm sure it will be resolved as well.
Let me get in touch with people involved in Gnome here at my company to see if they know more.
This may take a while as some are still gone this week.
Unfortunately, tinyxml2 has been in this state for ages. Since it doesn't have a lot of validation, the security flaws reported were just 'incarnations' of classes of issues that still exist and haven't been addressed.
I believe with libxml2 we are still better off - which should not serve as an excuse!

[Dave-Allured]

@E4, please clarify. What do you mean by "tinyxml2 has been in this state for ages"? We were just talking about a maintainer problem of libxml2, not tinyxml2.

By "validation" do you mean validation against security problems? And do you think one of these packages has better validation than the other? Thank you.

[e4t]

Sorry, I mixed package names up, I meant to say 'ezxml'. Which was the original xml implementation used by netcdf-c - where security issues had started to pile up.
I do not think the present situation around libxml2 will require immediate action as I believe libxml2 is used too much to be orphaned for too long. Still, one should keep an eye on it.
I've talked to a GNOME contributor: libxml2 predates GNOME and got 'included' in GNOME due to the people involved back then.
Maybe that's the problem and makes it difficult to find a maintainer (as described in the link above). It may have to be moved to its own project, eventually.
Sorry again for the confusion.

[Dave-Allured]

@e4t, I thought that was what you meant, but I needed to be certain. I am reassured by your additional remarks supporting libxml2. The original bundled ezxml is now history, so we don't need to think about that one any more.

I am still hoping to find out whether the newly-added tinyxml2 has a similar degree of security validation as libxml2.

[Dave-Allured]

Update. Libxml2 is back in current maintenance.
https://mail.gnome.org/archives/xml/2022-January/msg00001.html

Meanwhile, a quick look at the github site suggests that maintenance of tinyxml2 is now lagging.

Given the relative popularity of libxml2, my preference for the netCDF default flops back over to libxml2. There are other considerations. I will stop fussing about this. Unidata, do the right thing. Thanks.