serde_yml

serde_yml is a deprecated Rust crate that used to provide serde-compatible YAML serialization and deserialization backed by a C-FFI libyaml parser. Its final release, 0.0.13, strips that vulnerable C-FFI surface out entirely and re-implements every public item as a thin re-export of noyalib’s compat-serde-yaml feature, structurally fixing RUSTSEC-2025-0068 (a segfault-class unsoundness in the old Serializer.emitter field) while keeping existing call sites compiling unchanged.

The crate exists purely as a migration bridge: every re-exported item is marked #[deprecated], the README ships side-by-side diff snippets to three maintained alternatives (noyalib, serde-saphyr, yaml-rust2), and MIGRATION.md documents the full removed-surface mapping. It is not intended for new projects — only for teams who need existing serde_yml call sites to keep building while they move off the crate.

What You Get

• Drop-in re-exports of from_str, to_string, from_slice, from_reader, from_value, and to_value matching the pre-deprecation serde_yml API surface
• A structural fix for RUSTSEC-2025-0068 via removal of the C-FFI libyml parser from the dependency graph
• Compiler-enforced #[deprecated] warnings on every public item, pointing at MIGRATION.md
• Side-by-side migration diffs to three maintained alternatives: noyalib, serde-saphyr, and yaml-rust2
• A documented decision guide for choosing which alternative fits existing Value/Mapping usage

Common Use Cases

• Keeping a codebase compiling on cargo update while budgeting a migration off serde_yml
• Auditing which maintained YAML crate (noyalib, serde-saphyr, yaml-rust2) matches existing serde_yml::Value usage
• Suppressing RUSTSEC-2025-0068 in cargo audit/cargo deny with a documented rationale while the shim removes the actual unsound surface
• One-off scripts that still need YAML (de)serialization compiling against old serde_yml import paths without an immediate rewrite

Under The Hood

Architecture serde_yml 0.0.13 is architecturally a re-export shim rather than an implementation: src/lib.rs (98 lines) defines no original serialization or deserialization logic — every public symbol (from_reader, from_slice, from_str, from_value, to_string, to_value, to_writer, Deserializer, Error, Location, Mapping, Number, Result, Sequence, Serializer, Tag, TaggedValue, Value) is a pub use noyalib::compat::serde_yaml::{...} forward, and the value, mapping, and with sub-modules exist solely to keep pre-deprecation import paths (serde_yml::value::Value, serde_yml::with::singleton_map) resolving. A crate-level #![deprecated(...)] attribute propagates a compiler warning to every downstream call site, and the previous C-FFI parser (libyml) plus its Serializer.emitter field — the source of RUSTSEC-2025-0068 — have been removed from the dependency graph entirely rather than patched in place, so there is nothing left in this crate for the vulnerable code path to exist in.

Tech Stack The crate targets Rust edition 2021 with a rust-version floor of 1.85.0 (bumped specifically because noyalib needs edition-2024 support), and depends on exactly two runtime crates: noyalib (pinned to 0.0.5, default-features = false, with std and compat-serde-yaml features enabled) and serde 1.0.204. Dev-dependencies (serde_derive, indoc) support the test suite only. CI is delegated to reusable GitHub Actions workflows hosted in a separate sebastienrousseau/pipelines repo (rust-ci.yml with Codecov coverage, security.yml for security scanning, docs.yml for rustdoc-to-GitHub-Pages publishing with a custom doc.serdeyml.com domain), and [profile.release] is tuned for a minimal binary (codegen-units = 1, lto = true, strip = symbols, panic = abort) despite the crate itself containing no computational logic to optimize.

Code Quality tests/shim.rs (104 lines) is a smoke-test suite covering typed round-trips through from_str/to_string, from_slice, from_reader, and from_value/to_value, using unwrap() throughout since these are compile/behavior regression checks rather than production error-handling code. The examples/ tree carries over roughly twenty files organized into serializer/, with/, and value/ sub-directories, each demonstrating a specific pre-deprecation usage pattern (enums, optional/default fields, singleton-map variants, nested structures) so migrating users can diff old behavior against the shim’s. Security posture is handled explicitly rather than silently: .cargo/audit.toml and deny.toml both carry inline comments justifying why RUSTSEC-2025-0068 is deliberately ignored (the advisory tracks the crate as unmaintained rather than the specific code path, which the README explains at length). There are no type definitions of the crate’s own to assess — Value, Mapping, Number, Error, and friends are all inherited wholesale from noyalib.

What Makes It Unique There is no new API surface here by design — the entire point of the 0.0.13 release is that the public API is unchanged from earlier serde_yml versions, letting existing call sites recompile without edits. The genuinely notable design choice is the migration path itself: every re-exported item is individually #[deprecated]-annotated so the compiler — not just documentation — tells each caller where to look, MIGRATION.md provides a per-symbol mapping table for three different destination crates (noyalib, serde-saphyr, yaml-rust2) rather than prescribing one, and the README’s decision guide branches on what the caller actually uses (Value vs. typed-only, low-level libyml/loader vs. high-level) so the developer picks a proportionate replacement instead of a one-size-fits-all rewrite. As developer experience for a deprecation shim, this is more considered than most — but as an ongoing library API, there is nothing novel to evaluate since none of it is meant to be used long-term.