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

jawiggins 7 hours ago | parent | next [-]

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.

▲

sarchertech 6 hours ago | parent [-]

Only if it doesn’t use any unsafe code, which I don’t think is the case here.

	▲	5 hours ago \| parent \| next [-]
		[deleted]
	▲	jawiggins 6 hours ago \| parent \| prev [-]
		Is that true? I thought if you compiled a rust crate with, `#[deny(unsafe_code)]`, there would not be any issues. xmloxide has unsafe usage only in the the C FFI layer, so the rest of the system should be fine.

▲

blegge 8 hours ago | parent | prev | next [-]

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 2 hours ago \| parent [-]
		See: https://gitlab.gnome.org/GNOME/libxml2/-/issues/1023

▲

notpushkin 8 hours ago | parent | prev [-]

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 7 hours ago | parent [-]

Based on context, i kind of imagine they are more thinking of the issues surounding libxslt.

	▲	notpushkin an hour ago \| parent [-]
		libxslt part I can agree with. But xmloxide readme states XSLT support is a non-goal anyway?