Thoughts about libyaml-safer
wrenger opened this issue · comments
I recently found an interesting blogpost about making libyaml-unsafe more idiomatic and safe (libyaml-safer).
Might this interest you? The performance seems to be similar, but maybe it's easier to maintain and it seems to save some code in favor of std functions.
PS: I'm not affiliated with the author and don't know his plans with this library...
Author here. Thanks for the interest!
I have a fork of serde-yaml that replaces unsafe-libyaml with libyaml-safer here: https://github.com/simonask/serde-yaml
The fork passes all of serde-yaml's tests, but it still needs some love. Specifically it contains UB due to the way I quickly hacked together the way that buffers/readers are passed to the backend. If there is interest in this, I'd be happy to massage it into an acceptable state, and guidance is welcome. :-)
(Note, I think the UB may technically exists in the current code as well, but isn't detected by Miri due to the use of raw pointers? Not sure.)
There are multiple ways to fix it, with varying levels of impact. I'm also open to change libyaml-safer's API to better fit serde-yaml's use case.
I think it would be all right for someone else to maintain a Serde data format using the libyaml-safer crate, but for serde_yaml I do not plan to use it. Libyaml has been abandoned for years and the former maintainer is strongly pushing people toward https://github.com/pantoniou/libfyaml. My criterion for switching YAML backend is that it would need to be pure-Rust code derived from libfyaml via very close 1:1 translation with a maintainer that is dedicated to keeping it up to date with libfyaml development for several years, or it needs to be a clean-room Rust implementation of YAML that I consider promising and serious on par with libfyaml. I think libyaml-safer does not have line of sight to either of those outcomes and would just make them less likely if serde_yaml used it.
@dtolnay That makes a lot of sense. I don't think I am willing to commit to taking on the permanent distraction of actively maintaining libyaml-safer in perpetuity (due to bandwidth), and that would be a big problem for serde-yaml, an important infrastructural crate in the ecosystem.
The good news for whoever following is that serde-yaml is often an app-level dependency - few other library crates depend on it, so anyone interested in switching to a fork that uses libyaml-safer or another YAML implementation can typically do so with very little friction.
I will add this footnote: libfyaml as it is today is a fairly problematic library, not least due to the lack of Windows support. It still uses alloca() and other non-portable things. This means that a c2rust translation is not directly feasible, and a Rust port cannot be completely faithful to the original API. So a clean-room Rust implementation with feature parity seems more realistic, but that's an even bigger commitment, and there's just not enough hours in the day.