`serde_yaml` is officially dead

[laniakea64]

Our ftdetect test runner currently uses serde_yaml for deserializing the test cases specifications. But this crate is now officially dead, with last version ending in "+deprecated".

The unsafe-libyaml crate (by the same author) that serde_yaml depends on, also appears no longer maintained.

I'm looking into possible replacements as I get the chance.

[laniakea64]

The option that looks the best to me is yaml-peg with its serde support feature. I tried it in a VM and got it working with a minor code change.

But, I'm missing some information to decide whether we should go for it. The Cargo dependencies I've previously introduced to vim-just were largely based on either the crate or its author having some tie to something we already trust - Rust itself, just, or our pre-existing dependencies. I was unable to find such tie for yaml-peg, and lack the expertise to audit this crate directly myself.

@NoahTheDuke What do you think about using yaml-peg?

[NoahTheDuke]

I don't know that we need to change anything until our code starts breaking.

[laniakea64]

Yeah this probably isn't urgent since this only happened on 24/25 March, not even 2 weeks ago, and our code still works fine with the old version of serde_yaml we're using, and cargo audit doesn't take issue with this. But these libraries use a lot of unsafe Rust, and long-term use of unmaintained unsafe Rust would seem unwise.

I'm fine with postponing this for now.

[laniakea64]

Another candidate exists now - https://crates.io/crates/serde_yaml2

[laniakea64]

Needed a serde YAML crate for something I was experimenting with, so decided to revisit this while at it.

Let's switch to serde_yaml2:

• For us it is a drop-in replacement for serde_yaml.
• One of the maintainers of its backend yaml-rust2 is trusted by a member of the rust-lang Github organization.
• Its dependencies look more maintained than yaml-peg's dependencies
• Quick grep found no unsafe Rust code in either serde_yaml2 or yaml-rust2, so if one of these were to become unmaintained, it'd likely be less concern than serde_yaml being unmaintained.
• I can almost read serde_yaml2's code well enough to vet it, and it looks reasonable to me.
• FWIW, dtolnay, Rust developer & serde_yaml maintainer, is watching the serde_yaml2 repository.

Also happened on something that has potential to become reason not to wait too long before replacing serde_yaml, but quick Internet search didn't find any sign of that potential being a reality at this time.

[laniakea64]

cargo audit doesn't take issue with this

There is now movement on filing an advisory about serde_yaml, so removing the "on hold" tag. If no objections to using serde_yaml2, I'll address this along when it's time to remove the once_cell dependency.