6 ms·

Show HN: Xmloxide – an agent-made Rust replacement for libxml2

64 points by jawiggins 7mo ago

Recently several AI labs have published experiments where they tried to get AI coding agents to complete large software projects. - Cursor attempted to make a browser from scratch: https://cursor.com/blog/scaling-agents https://cursor.com/blog/scaling-agents - Anthropic attempted to make a C Compiler: https://www.anthropic.com/engineering/building-c-compiler https://www.anthropic.com/engineering/building-c-compiler I have been wondering if there are software packages that can be easily reproduced by taking the available test suites and tasking agents to work on projects until the existing test suites pass. After playing with this concept by having Claude Code reproduce redis and sqlite, I began looking for software packages where an agent-made reproduction might actually be useful. I found libxml2, a widely used, open-source C language library designed for parsing, creating, and manipulating XML and HTML documents. Three months ago it became unmaintained with the update, "This project is unmaintained and has [known security issues](https://gitlab.gnome.org/GNOME/libxml2/-/issues/346 https://gitlab.gnome.org/GNOME/libxml2/-/issues/346). It is foolish to use this software to process untrusted data.". With a few days of work, I was able to create xmloxide, a memory safe rust replacement for libxml2 which passes the compatibility suite as well as the W3C XML Conformance Test Suite. Performance is similar on most parsing operations and better on serialization. It comes with a C API so that it can be a replacement for existing uses of libxml2. - crates.io: https://crates.io/crates/xmloxide https://crates.io/crates/xmloxide - GitHub release: https://github.com/jonwiggins/xmloxide/releases/tag/v0.1.0 https://github.com/jonwiggins/xmloxide/releases/tag/v0.1.0 While I don't expect people to cut over to this new and unproven package, I do think there is something interesting to think about here in how coding agents like Claude Code can quickly iterate given a test suite. It's possible the legacy code problem that COBOL and other systems present will go away as rewrites become easier. The problem of ongoing maintenance to fix CVEs and update to later package versions becomes a larger percentage of software package management work.

man4 7mo ago
[dead]
blegge 7mo ago
> arena-based tree with zero unsafe in the public API Why "in the public API"? Does this imply it's using unsafe behind the hood? If so, what for?
- DetroitThrow 7mo ago
  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.
  - mirashii 7mo ago
    It is a measure of the intended level of care that the users of your interface have to take. If there's no unsafe in the interface, then that implies that the library has only provided safe interfaces, even if it uses unsafe internally, and that the interface exposed enforces all necessary invariants. It is absolutely a useful distinction on whether your users need to deal with unsafe themselves or not.
    - DetroitThrow 7mo ago
      Sure, it's a useful distinction for whether users need to care about safety but not whether the underlying code is safe itself, which is what I wrote about. No or very little but verified unsafe internal code is the bar for many Rust reimplementations. It would also be what keeps the code memory safe.
    - ahepp 7mo ago
      I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum? I find it difficult to believe the rust community would accept using a library where the API requires unsafe.
      - DetroitThrow 7mo ago
        >I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum I have some experience and yes, unless you're putting out a library for specifically low-level behavior like manual memory management or FFI. Trivia about the unsafe fn keyword missed the point of my comment entirely.
fourthark 7mo ago
Does it fix the security flaws that caused the original project to be shut down?
- blegge 7mo ago
  https://gitlab.gnome.org/GNOME/libxml2/-/commit/0704f52ea4cd0cf82253bb2af3f70a09d428629d 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?
  - fweimer 7mo ago
    See: https://gitlab.gnome.org/GNOME/libxml2/-/issues/1023 https://gitlab.gnome.org/GNOME/libxml2/-/issues/1023
- notpushkin 7mo ago
  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.
  - bawolff 7mo ago
    Based on context, i kind of imagine they are more thinking of the issues surounding libxslt.
    - notpushkin 7mo ago
      libxslt part I can agree with. But xmloxide readme states XSLT support is a non-goal anyway?
- jawiggins 7mo ago
  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.
nicoburns 7mo ago
How does it compare to the original in terms of source code size (number of lines of code?)
- jawiggins 7mo ago
  It's significantly smaller. Because Rust doesn't require header files or memory management, xmloxide is ~40k lines while libxml2 is ~150k lines.
kburman 7mo ago
Amazing work! I'd love to hear more details about your workflow with Claude Code. As a side note and this isn't a knock on your project specifically. I think the community needs to normalize disclaimers for "vibe-coded" packages. Consumers really need to understand the potential risks of relying on agent-generated code upfront.
- jawiggins 7mo ago
  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.
  - tonyedgecombe 7mo ago
    Yes, if you tripped across this package in crates.io the readme gives the impression of a serious piece of software but your comments here imply it is a one off experiment rather than something you plan to maintain for the next decade.
  - kelnos 7mo ago
    I don't think it was irresponsible to publish it, but I do think it was irresponsible to publish it without clearly disclosing at the top of the crates.io README that it was built entirely by AI, and that you haven't reviewed the code (assuming you haven't). If I were looking for an XML parser/generator library, I might stumble across this and think it might be production-quality, and assume it was built by humans, or at least that humans had fully vetted and understand the code.
prima-facie 7mo ago
A comment on libxml, not on your work: Funny how so many companies use this library in production and not one steps in to maintain this project and patch the issues. What a sad state of affairs we are in.
- black_13 7mo ago
  [dead]
- jawiggins 7mo ago
  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.
  - da_chicken 7mo ago
    There should be public works grants to maintain them, or else a foundation specifically to maintain them funded with donations, grants, etc. The alternative is another XZ backdoor.
  - mathstuf 7mo ago
    > 1) There could probably be tax credits or deductions for SWEs who 'volunteer' their time to work on these projects. Why exclusive to SWEs? They tend to be more time-restricted than financial-restricted (assuming the "SWE" comes from a job description). I'd be more interested in making sure that those with less well-paying jobs are able to access such benefits rather than stacking it onto those already (probably) making 6-figures. Of course, the problems arise in the details. Define "volunteer": if $DAYJOB also uses it (in a way related to my role), is it actually, instead, wage theft? Also, quantifying the benefit is a sticky question. Is maintaining 10k emoji packages on NPM equivalent to volunteer work on libcurl? Could it ever be? Is it volunteer work if it ends up with a bug bounty payday? Google's fuzzing grant incentives?
alexhans 7mo ago
> I do think there is something interesting to think about here in how coding agents like Claude Code can quickly iterate given a test suite. This is a point I've tried to advocate for a while. Specially to empower non coders and make them see that we CAN approach automation with control. Some aspects will be the classic unit or integration tests for validation. Others, will be AI Evals [1] which to me could be the common language for product design for different families/disciplines who don't quite understand how to collaborate with each other. The amount of progress in a short time is amazing to see. - [1] https://ai-evals.io/ https://ai-evals.io/
- koakuma-chan 7mo ago
  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.
  - alexhans 7mo ago
    I respectfully disagree. I think there needs to be a common term for the aspects around LLM testing and saying "It's just integration/system tests" doesn't really reach audiences well. They don't disambiguate the differences. Words win when they're used. Just because Agent Skills is just a pattern for standarization and saving context doesn't mean it wasn't incredibly useful. Think beyond software developers by trade. Think beyond people those who realized they needed tests instead of those who thought "the models will just get smarter" and "they told me there's guardrails".
benatkin 7mo ago
It would be interesting to try this approach out with mQuickJS, QuickJS or micropython. They could potentially run hoops around the ones that were first coded in Rust, such as Boa or RustPython.
lynxbot2026 7mo ago
[flagged]
- jawiggins 7mo ago
  Yes, in testing I did add four fuzzing targets to the repo: 1. fuzz_xml_parse: throws arbitrary bytes at the XML parser in both strict and recovery mode 2. fuzz_html_parse: throws arbitrary bytes at the HTML parser 3. fuzz_xpath: throws arbitrary XPath expressions at the evaluator 4. fuzz_roundtrip: parse → serialize → re-parse, checking that the pipeline never panics Because this project uses memory safe rust, there isn't really the need to find the memory bugs that were the majority of libxml2's CVEs. There is a valid point about logic bugs or infinite loops, which I suppose could be present in any software package, and I'm not sure of a way to totally rule out here.
  - agentifysh 7mo ago
    pretty sure you are replying to a bot seems like they make a new account just to leave short drive by comments this is like the 8th green handle i've seen so far recently with similar style of comments I suspect is AI generated
mkj 7mo ago
Intriguing work! Does it panic on any bad inputs? That's better than memory unsafety of libxml2, but still a DoS concern for some servers.
hrtla 7mo ago
Yes, you can rip off any sucker who published a test suite when the AI is trained on existing code as well. Congratulations, you will be showered with praise and AI mafia money.
mdavid626 7mo ago
Can you add “made with AI” to the GitHub repo? It’s time to make this mandatory. Nothing against AI - just to inform people about quality, maintainability and future of this library. No human has mental model of the code, so don’t waste your time creating it - the original author didn’t either.
- agentifysh 7mo ago
  what would be the point ? why should this be mandatory ? none of your arguments make sense here
  - kelnos 7mo ago
    GP literally tells you the point in the last paragraph. Makes perfect sense to me.
    - agentifysh 7mo ago
      and why should that be solved by "made by AI" being mandatory label when pretty much all of coding now involves it
      - mdavid626 7mo ago
        Involves and made only by, are 2 different things. I use agentic coding in my daily work. I do make mental model of the code I write and I also test the code, exactly the same way, as when written completely manually.
        agentifysh 7mo ago
        Ah, so the code doesn't need an AI label as long as you promise you thought really hard about it before copy-pasting.
        invaliduser 7mo ago
agentifysh 7mo ago
lot of weird comments here getting upset AI was used but thanks for doing this libxml2 is always one of those libraries that i used to have trouble with for different platforms I think its great that more and more OSS projects get attention now with ai coding agents
dmitrygr 7mo ago
cool, now do it without the test suite that some human made for you
yobbo 7mo ago
The code might be a little verbose which is tiresome for humans to read and follow. Structure and functions look idiomatic. It seems to be using xml parser idioms which makes it readable. It could be doing double checks in both tokeniser and parser and things like that. Actually looks like a good starting point and reference for someone working on xml parsers in rust.
Imustaskforhelp 7mo ago
Can this work with XLSX (The Open XML format) & .odt format though these also use zip. It would be interesting to think if this can help solve this and create a rust GUI app with very basic XLSX doc editing as alternative to OpenOffice/LibreOffice.

64 points by jawiggins 7mo ago

man4 7mo ago

[dead]

blegge 7mo ago

> arena-based tree with zero unsafe in the public API Why "in the public API"? Does this imply it's using unsafe behind the hood? If so, what for?

DetroitThrow 7mo ago
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.
- mirashii 7mo ago
  It is a measure of the intended level of care that the users of your interface have to take. If there's no unsafe in the interface, then that implies that the library has only provided safe interfaces, even if it uses unsafe internally, and that the interface exposed enforces all necessary invariants. It is absolutely a useful distinction on whether your users need to deal with unsafe themselves or not.
  - DetroitThrow 7mo ago
    Sure, it's a useful distinction for whether users need to care about safety but not whether the underlying code is safe itself, which is what I wrote about. No or very little but verified unsafe internal code is the bar for many Rust reimplementations. It would also be what keeps the code memory safe.
  - ahepp 7mo ago
    I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum? I find it difficult to believe the rust community would accept using a library where the API requires unsafe.
    - DetroitThrow 7mo ago
      >I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum I have some experience and yes, unless you're putting out a library for specifically low-level behavior like manual memory management or FFI. Trivia about the unsafe fn keyword missed the point of my comment entirely.

fourthark 7mo ago

Does it fix the security flaws that caused the original project to be shut down?

blegge 7mo ago
https://gitlab.gnome.org/GNOME/libxml2/-/commit/0704f52ea4cd0cf82253bb2af3f70a09d428629d 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?
- fweimer 7mo ago
  See: https://gitlab.gnome.org/GNOME/libxml2/-/issues/1023 https://gitlab.gnome.org/GNOME/libxml2/-/issues/1023
notpushkin 7mo ago
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.
- bawolff 7mo ago
  Based on context, i kind of imagine they are more thinking of the issues surounding libxslt.
  - notpushkin 7mo ago
    libxslt part I can agree with. But xmloxide readme states XSLT support is a non-goal anyway?
jawiggins 7mo ago
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.

nicoburns 7mo ago

How does it compare to the original in terms of source code size (number of lines of code?)

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

kburman 7mo ago

Amazing work! I'd love to hear more details about your workflow with Claude Code. As a side note and this isn't a knock on your project specifically. I think the community needs to normalize disclaimers for "vibe-coded" packages. Consumers really need to understand the potential risks of relying on agent-generated code upfront.

jawiggins 7mo ago
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.
- tonyedgecombe 7mo ago
  Yes, if you tripped across this package in crates.io the readme gives the impression of a serious piece of software but your comments here imply it is a one off experiment rather than something you plan to maintain for the next decade.
- kelnos 7mo ago
  I don't think it was irresponsible to publish it, but I do think it was irresponsible to publish it without clearly disclosing at the top of the crates.io README that it was built entirely by AI, and that you haven't reviewed the code (assuming you haven't). If I were looking for an XML parser/generator library, I might stumble across this and think it might be production-quality, and assume it was built by humans, or at least that humans had fully vetted and understand the code.

prima-facie 7mo ago

A comment on libxml, not on your work: Funny how so many companies use this library in production and not one steps in to maintain this project and patch the issues. What a sad state of affairs we are in.

black_13 7mo ago
[dead]
jawiggins 7mo ago
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.
- da_chicken 7mo ago
  There should be public works grants to maintain them, or else a foundation specifically to maintain them funded with donations, grants, etc. The alternative is another XZ backdoor.
- mathstuf 7mo ago
  > 1) There could probably be tax credits or deductions for SWEs who 'volunteer' their time to work on these projects. Why exclusive to SWEs? They tend to be more time-restricted than financial-restricted (assuming the "SWE" comes from a job description). I'd be more interested in making sure that those with less well-paying jobs are able to access such benefits rather than stacking it onto those already (probably) making 6-figures. Of course, the problems arise in the details. Define "volunteer": if $DAYJOB also uses it (in a way related to my role), is it actually, instead, wage theft? Also, quantifying the benefit is a sticky question. Is maintaining 10k emoji packages on NPM equivalent to volunteer work on libcurl? Could it ever be? Is it volunteer work if it ends up with a bug bounty payday? Google's fuzzing grant incentives?

alexhans 7mo ago

> I do think there is something interesting to think about here in how coding agents like Claude Code can quickly iterate given a test suite. This is a point I've tried to advocate for a while. Specially to empower non coders and make them see that we CAN approach automation with control. Some aspects will be the classic unit or integration tests for validation. Others, will be AI Evals [1] which to me could be the common language for product design for different families/disciplines who don't quite understand how to collaborate with each other. The amount of progress in a short time is amazing to see. - [1] https://ai-evals.io/ https://ai-evals.io/

koakuma-chan 7mo ago
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.
- alexhans 7mo ago
  I respectfully disagree. I think there needs to be a common term for the aspects around LLM testing and saying "It's just integration/system tests" doesn't really reach audiences well. They don't disambiguate the differences. Words win when they're used. Just because Agent Skills is just a pattern for standarization and saving context doesn't mean it wasn't incredibly useful. Think beyond software developers by trade. Think beyond people those who realized they needed tests instead of those who thought "the models will just get smarter" and "they told me there's guardrails".

benatkin 7mo ago

It would be interesting to try this approach out with mQuickJS, QuickJS or micropython. They could potentially run hoops around the ones that were first coded in Rust, such as Boa or RustPython.

lynxbot2026 7mo ago

[flagged]

jawiggins 7mo ago
Yes, in testing I did add four fuzzing targets to the repo: 1. fuzz_xml_parse: throws arbitrary bytes at the XML parser in both strict and recovery mode 2. fuzz_html_parse: throws arbitrary bytes at the HTML parser 3. fuzz_xpath: throws arbitrary XPath expressions at the evaluator 4. fuzz_roundtrip: parse → serialize → re-parse, checking that the pipeline never panics Because this project uses memory safe rust, there isn't really the need to find the memory bugs that were the majority of libxml2's CVEs. There is a valid point about logic bugs or infinite loops, which I suppose could be present in any software package, and I'm not sure of a way to totally rule out here.
- agentifysh 7mo ago
  pretty sure you are replying to a bot seems like they make a new account just to leave short drive by comments this is like the 8th green handle i've seen so far recently with similar style of comments I suspect is AI generated

mkj 7mo ago

Intriguing work! Does it panic on any bad inputs? That's better than memory unsafety of libxml2, but still a DoS concern for some servers.

hrtla 7mo ago

Yes, you can rip off any sucker who published a test suite when the AI is trained on existing code as well. Congratulations, you will be showered with praise and AI mafia money.

mdavid626 7mo ago

Can you add “made with AI” to the GitHub repo? It’s time to make this mandatory. Nothing against AI - just to inform people about quality, maintainability and future of this library. No human has mental model of the code, so don’t waste your time creating it - the original author didn’t either.

agentifysh 7mo ago
what would be the point ? why should this be mandatory ? none of your arguments make sense here
- kelnos 7mo ago
  GP literally tells you the point in the last paragraph. Makes perfect sense to me.
  - agentifysh 7mo ago
    and why should that be solved by "made by AI" being mandatory label when pretty much all of coding now involves it
    - mdavid626 7mo ago
      Involves and made only by, are 2 different things. I use agentic coding in my daily work. I do make mental model of the code I write and I also test the code, exactly the same way, as when written completely manually.
      - agentifysh 7mo ago
        Ah, so the code doesn't need an AI label as long as you promise you thought really hard about it before copy-pasting.
        invaliduser 7mo ago

agentifysh 7mo ago

lot of weird comments here getting upset AI was used but thanks for doing this libxml2 is always one of those libraries that i used to have trouble with for different platforms I think its great that more and more OSS projects get attention now with ai coding agents

dmitrygr 7mo ago

cool, now do it without the test suite that some human made for you

yobbo 7mo ago

The code might be a little verbose which is tiresome for humans to read and follow. Structure and functions look idiomatic. It seems to be using xml parser idioms which makes it readable. It could be doing double checks in both tokeniser and parser and things like that. Actually looks like a good starting point and reference for someone working on xml parsers in rust.

Imustaskforhelp 7mo ago

Can this work with XLSX (The Open XML format) & .odt format though these also use zip. It would be interesting to think if this can help solve this and create a rust GUI app with very basic XLSX doc editing as alternative to OpenOffice/LibreOffice.