It's not exactly a left-pad situation, because the package remains fully functional (and crates.io doesn't allow deletions), but the package is used in 4000 other crates. Audit and auto-update tools will be complaining about use of an unmaintained crate.
You seem to be misunderstanding the comic you link.
With him that was the situation.
On crates.io, serde_yaml has 56m lifetime downloads and 8.5m recent downloads, and from his own announcement David hasn't used yaml in any of his project in a while, yet has kept plugging at it until now.
And yaml-rust has 53.5m lifetime downloads and 5m recent downloads, and has been unmaintained for 4 years.
Not the case here but sometimes a library (with no dependencies) is really feature complete with no real need for changes other than security fixes.
I wish audit tools and corporate policies are smart enough to recognize this instead of nagging about "unmaintained" versions of projects with no recent commits.
The ball is in the court of the enterprise purchaser mandating the auditing company and they don’t give a ** if your dev team has to hot swap a yaml parsing library
So you have security theater and TPS reports consuming the time of some of your most highly compensated human resources.
Agreed but the gotcha is when a new issue comes out and there is no security fix available. It would be enough to say 'we are comfortable patching this if a CVE is found', but at that point they might as well start to maintain it.
The issue is that the context is always changing. It is almost like suggesting there is an evolutionarily perfect organism. At best, one suited perfectly well to the current context can exist, but that perfect suitability falls off the second the environment changes. And the environment always changes.
I totally get the sentiment, but I think the idea that any code is ever complete is unfortunately just not a realistic one to apply outside of select and narrow contexts.
It's not like it's desirable for standard formats to one day start getting interpreted in a different way.
You depend on calling a standard library function that was found deficient (maybe it's impossible to make it secure) and deprecated. Now there is a new function you should call. Your software doesn't work anymore when the deprecated function is removed.
Sure, you can say your software is feature complete but you have to specify the external environment it's supposed to run on. And THAT is always changing.
You're both right but looking at different timelines.
Relevant: https://www.oreilly.com/library/view/software-engineering-at...
That's a biiiiig if
There are Clojure packages that go untouched for years... not because they're abandoned, but because they are stable and good enough.
The release notes for the last release explain: https://github.com/dtolnay/serde-yaml/releases/tag/0.9.34
This is an unrealistic and frankly a bit entitled of a criticism.
This is before we even get to stuff like “it’s not like yaml is a fast moving target, what continued maintenance is really even needed” parts of the equation, or the comment above that said he’s tried already.
We should remember that an unmaintained dependency isn’t the worst thing that can happen to a supply chain. There are far worse nightmare scenarios that involve exfiltrated keys, ransomewared files and such.
I’ll bet that if someone with a track record of contributing to the Rust community steps up, he’ll happily transfer control of the crate. But he’s not just going to assign it to some random internet user and put the whole ecosystem at risk.
I think he was generous enough with his time for creating the library in the first place and posting this update. It's not like he's owing anything to anybody. I don't understand how you can demand him to do further UNPAID work to recruit maintainers who would also do further unpaid work.
Why can't this "someone else" just fork the repo themselves?
Are we collectively having Subversion phantom pains or something? Just take it.
You can't. Ever. This is unironically why languages too old for package repositories like C and C++ lend themselves to stabler, higher-quality software.
On top of that is also the entitlement to feel like people providing you software for free MUST ALSO be responsible for polishing it forever. But, hey, I guess that attitude comes naturally with the package repository mindset. ;D People need to do all my work for me!
> stabler, higher-quality software.
Lol I’ll have some too buddy
https://github.com/dtolnay/serde-yaml/releases/tag/0.9.34
> As of this release, I am not planning to publish further versions of serde_yaml as none of my projects have been using YAML for a long time, so I have archived the GitHub repo and marked the crate deprecated in the version number.
I don't think anyone is claiming he is legally required to do it. Just that it would be nice. But in this case I think he did try to look for someone anyway.
Maybe this description is wrong but I can’t tell.
stuff -> insta
learned-rust-this-way -> yaml-rust
to default/defaulted -> serde-yaml
As I read it: insta was depending on yaml-rust. RUSTSEC issued an advisory against yaml-rust. Some shade is thrown on yaml-rust for being unmaintained and basically a student project of someone learning the language for the first time, adding to the irony/brittleness of its unmaintained (though still working) state and now the RUSTSEC callout. In insta trying to switch to some alternative to yaml-rust the next most common library serde-yaml preemptively announced its unmaintained status. So insta just vendored yaml-rust and called it a day, which currently works to remove the RUSTSEC complaints but doesn't fix the long term maintenance problem.
FTFY. And vendoring a dependency is really just a hidden fork.
It's not a fork until you start diverging from upstream with local modifications.
I mean, implementing your fixes in the first place means you are already inherently forking it.
1. You find a bug, open an issue. 2. If bug is a minor issue, wait. If I want a fix really bad, offer to fix it. 3. If I still want a fix really bad and author did not respond, or does not want a fix, then fork the project for my own consumption. Using alternative dependencies are also an option.
Imo be ready to fork all the things if need be. Get comfortable with it before you're forced to.
cargo update
For example I can’t imagine Ford checks literally every single individual component that gets put in their cars, right? I assume they have contracts and standards with manufacturers that make the parts, probably including random spot checks, but at some point to handle complexity it is necessary to trust/offload responsibility on some suppliers.
I bet you could get those sort of guarantees from, like, Intel or IBM if people generally were willing to pay them enough (can you now? Not sure, probably depends on the specific package). But nobody would make that sort of promise for free. The transparency of the open source ecosystem is an alternative to that sort of thing, no promises but you can check everything.
Just to be explicit (since I’m sure this looks like needless pedantry), I think it is important to remember that the open source and free software ecosystems are an active rejection of that sort of liability management framework, because that’s the only way to get contributions from a community of volunteers.
As a software assembly designer, I don't really have any way to say "this subcomponent remains intact" when I integrate it into my system. The compiler will chew things up and rearrange them at link time. This is a good thing! It makes the resulting binary go brr real good. But it's ultimately my responsibility to make sure the thing I ship--the compiled artifact--is correct. It's not really a valid move to blame one of my dependencies. I was supposed to review those dependencies and make sure they work in the context of the thing I shipped. Wouldn't it be a bit like the mechanical assembly designer blaming the bolt manufacturer for a failure of a bolt they modified while building the assembly (EDIT: or blaming the supplier when the assembler used the bolt in a way it wasn't designed for)? What guarantees can the bolt manufacturer reasonably give in that case?
EDIT: another thing is that source code isn't really analogous to a mechanical component. It's more like the design specification or blueprint for... something that converts electrical potential into heat and also does other stuff.
So yes, I `cargo update`.
Why would he?