About a day after I resigned as maintainer, SUSE stepped in and is now maintaining the project. As announced here [1], I'm currently trying a different funding model and started a GPL-licensed fork with many security and performance improvements [2].

It should also be noted that the remaining security issues in the core parser have to do with algorithmic complexity, not memory safety. Many other parts of libxml2 aren't security-critical at all.

[1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/976

[2] https://codeberg.org/nwellnhof/libxml2-ee

Yeah I agree, maintaining OS projects has been a weird thing for a long time.

I know a few companies have programs where engineers can designate specific projects as important and give them funds. But it doesn't happen enough to support all the projects that currently need work, maybe AI coding tools will lower the cost of maintenance enough to improve this.

I do think there are two possible approaches that policy makers could consider.

1) There could probably be tax credits or deductions for SWEs who 'volunteer' their time to work on these projects.

2) Many governments have tried to create cyber reserve corps, I bet they could designate people as maintainers of key projects that they rely on to maintain both the projects as well as people skilled with the tools that they deem important.

funny how this myth won't die. Checking the commit history plenty of companies are contributing

redhat, apple, samsung, huawei, google, etc...

we need a tax on companies using or selling anything OSS, the funds of which go into OSS, the wealth it generated is insane, and it's nearly all just donations of experts

Feels like tragedy of the commons.

Even more interesting is how much did the effort cost.

Unlike the development work of old (pre-2025), work with high-end models incurs a very direct monetary cost, one burns tokens which cost money, and you can't have something as powerful to be running locally (even if you happened to have a Mac Pro Ultra with RAM maxed out).

Some of my friends burned through hundreds of dollars a day while doing large amounts of (allegedly efficient) work with Claude Code.

Yeah its a fair point. I wondered if it might be irresponsible to publish the package because it was made this way, but I suspect I'm not the first person to try and develop a package with Claude Code, so I think the best I can do is be honest about it.

As for the workflow, I think the best advice I can give is to setup as many guardrails and tools as possible, so Claude and do as many iterations before needing any intervention. So in this case I setup pre-commit hooks for linting and formatting, gave it access to the full testing suite, and let it rip. The majority of the work was done in a single thinking loop that lasted ~3 hours where Claude was able to run the tests, see what failed, and iterate until they all passed. From there, there was still lots of iterations to add features, clean up, test, and improve performance - but allowing Claude to iterate quickly on it's own without my involvement was crucial.

Do they? Tons of extremely popular human generated libraries are absolute trash. Just as an example, nearly all of the JS zip file libraries are dumpers fires. Same with QR code libraries and command line parsing libraries.

This feels like if you want to know if the code is good or bad, read the code and check the tests. Assuming human = good, LLM = bad does not make much sense given the amount of bad human code I've seen.

Sure, if the code is from a repuatable company or creator then I'd take that as a strong signal quality over an LLM but I wouldn't take a random human programmer as a strong signal over generated.

Please stop spreading this "AI evals" terminology. "evals" is what providers like OpenAI and Anthropic do with their models. If you wrote a test for a feature that uses an LLM, it's just a test, there's no need to say "evals." Having a separate term only further confuses people who already have no idea what that actually means.

I agree the wording is a bit strange, but a quick grep of the repo shows that it doesn't imply that.

The only usages of unsafe are in src/ffi, which is only compiled when the ffi feature is enabled. ffi is fundamentally unsafe ("unsafe" meaning "the compiler can't automatically verify this code won't result in undefined behavior") so using it there is reasonable, and the rest of the crate is properly free of unsafe.

It provides a libxml2-compatible C API and that accepted pointers, this would seem to necessitate unsafe at least.

Yeah I'm a bit confused because you can have an entirely unsafe code base with just the public interface marked as safe. No unsafe in the interface isn't a measure of safety at all.

It's significantly smaller. Because Rust doesn't require header files or memory management, xmloxide is ~40k lines while libxml2 is ~150k lines.

Because it was written in C, libxml2's CVE history has been dominated by use-after-free, buffer overflows, double frees, and type confusion. xmloxide is written in pure Rust, so these entire vulnerability classes are eliminated at compile time.

https://gitlab.gnome.org/GNOME/libxml2/-/commit/0704f52ea4cd...

Doesn't seem to have shut down or even be unmaintained. Perhaps it was briefly, and has now been resurrected?

If by flaws you mean the security researchers spamming libxml2 with low effort stuff demanding a CVE for each one so they can brag about it – no, I don’t think anybody can fix that.

what would be the point ? why should this be mandatory ?

none of your arguments make sense here