3 ms·

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.
  • sarchertech 7mo ago
    Only if it doesn’t use any unsafe code, which I don’t think is the case here.
    • jawiggins 7mo ago
      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.
    • deleted 7mo ago
      [deleted]