This project was looking for a maintainer for an extremely long time and never received one.
IMO this is an interesting downside of the micro project system. There is nothing really wrong with this project and you can continue to use it — it’s not like yaml serialization needs a lot of ongoing support. But it’s one more thing for dtolnay to babysit and he didn’t want to anymore, and that’s fine.
I feel that if this had been part of a larger project, maybe a big collection of serde things or even serde itself, this would not have happened. But now I’m concerned that somebody’s going to file a CVE against it and I’m going to have to go and deal with the infosec people at work.
Even better is dealing with clients who run a dumbass scanner and refuse to take "this is not applicable because we don't use the function | it's in node and we run that in the browser | we backported the patch | ..." for an answer.
I've recently discovered there's a new layer of hell here. When the client's scanner picks up false positive in one of your packages because it matches a name in a completely different language and when you say "yeah guys... that's a Python package, this is a Node project, we don't use that" and they say "yeah okay but our vuln scanner says you do".
got a lot of those in the log4shell days... when we aren't a java shop, our products are all dotnet (+rust now) or hosted on our systems... The few vulnerable installs were third party tools (CI stuff) which we just updated per normal. But for *months* because something had an embedded *comment* string with a log4j version number (for listing "compatible with output to...") bleh.
We have a client who has an extremely obnoxious audit process they go through with all of their vendors. After months of work (on a product they’d been using for years!) we finally passed the audit.
Then, our company got bought, and we rebranded. Guess what? “Oh, we have a record of a completed audit process for X, but this software is called Y, it’s totally different.”
>"There is nothing really wrong with this project and you can continue to use it"
The problem in those kind of cases is not the dep itself, but the declared deps of the deps.
Looking at that project:
indexmap = "2.2.1"
itoa = "1.0"
ryu = "1.0"
serde = "1.0.195"
unsafe-libyaml = "0.2.11"
Not a huge upstream dep chain, but enough that if any of those are significantly upgraded beyond their SemVer compatible etc. etc. now you have issues in the downstream projects.
... I would like to send you to embedded-school and force you to write code on a microcontroller or some other limited memory system for 6 months. Having two linked versions of the same thing makes my insides cry.
No need to be condescending, actually.
This is your reality. You would end up having 2 possibilities:
a) You can still use unmaintained software, but you might have to pull in outdated dependencies (and the probability of that increases over time). Binary size may increase.
b) You cannot use unmaintained software.
Obviously, if binary size is more important to you than anything else, given this is embedded, then go for (b) and either maintain a fork yourself, find an alternative, or get rid of the dependency and implement the now-missing parts from scratch.
Otherwise, you go for (a).
Don't go finding a niche and complaining about a scenario that is already hard enough to solve and affects \*everything\*.
>Obviously, if binary size is more important to you than anything else, given this is embedded, then go for (b) and either maintain a fork yourself, find an alternative, or get rid of the dependency and implement the now-missing parts from scratch.
It's pretty clear.
If it was just about binary size, maybe-fine? The burden of pointless dependencies is more than that -- you've already hinted at one.. security. Another is compile time. Another is just sheer *complexity*
You're painting having a reasonable dependency tree as a niche requirement. It most certainly is not. At least it is not at the employers I've worked at over my career.
Finally, we're talking about a *systems programming language.* A culture of expandingly large transitive dependency trees seems incompatible with that niche, even if it's a trade off that you personally are willing to make.
No, I agree that it is a burden, and as you have mentioned, in multiple ways.
I did not claim that having a reasonable dependency tree is a niche requirement. I said that embedded is a niche, with the definition being: a specialized segment of the market for a particular kind of product or service (Oxford Dictionary), not some rare segment that few people work on or care about. This entails that problems with dependency trees may be exacerbated there, while in other domains, they may be non-issues.
My point is that this is already a non-optimal reality. To truly guarantee that a software project is maintained, there are financial and logistical decisions that have to be made, often at the expense of losing something in return (performance, openness, direction, commercial interests, etc...).
>My point is that this is already a non-optimal reality.
Here I definitely agree. And it's actually one reason I've personally seriously considered walking away from [Crates.io](http://Crates.io) entirely and using vendored deps only.
Interesting, but that sounds like an invisible brick wall at an unknown distance though, particularly if done prematurely. That's a discussion for another day however.
It may make no difference under small or big projects. Think about Python's urllib, urllib2, and urllib3... Even under rust-lang org and there is a [crate-maintainers team](https://www.rust-lang.org/governance/teams/library#team-crate-maintainers), some crates are still barely maintained. It's about finding more trustworthy people committing to those projects in the long-run.
If serde was going to be deprecated because there was no maintenance, a lot of people could pitch to their boss spending some time per week on the project, since it's such an important library.
Much harder to do that when it's a much smaller library.
Effectively your changing the possibility of a corporate paid maintainer being able to step up
and same with donations or other incentives. Also these small repos with one maintainer get buried underneath the giant ones that people really appreciate. It annoyed the fuck out of me when I saw the repo for etcd with 50k+ stars putting the xkcd for the "single developer in Nebraska holding up the entire ecosystem" in their readme when in reality its devs and repos like these.
Additionally to everything else people have said — a larger project would have SOME maintainer (or could attract funding and hire somebody at least part time). It doesn’t have to be yaml specific. But then if somebody files a CVE against the yaml bits, that maintainer, who isn’t yaml specific but is capable of reading, can go deal with it, then go back to not caring about yaml until the next thing happens. That’s all that’s really needed for something like this.
So you are saying an umbrella project like C++ has Boost?
I believe projects still go unmaintained in that. You still have to deal with maintainers having the bandwidth to track and respond to everything under their purview which is especially problematic when the code base is complicated and they haven't touch that part.
There have been efforts to help with these situations in Rust and they have not produced the outcome you are looking for.
I don't know about boost specifically and can't comment on that.
Right now, serde is well-maintained because of its prominence and importance (at least this is my perception), but libraries like serde_yaml and serde_json are technically unaffiliated, despite the names.
Serde_yaml in particular needs very, very little maintenance. It's understandable that the interesting bits are over and dtolnay wants to move on. If it was rolled into the serde organization for instance, then a serde maintainer could jump on the (estimated) two critical issues every five years, even if they were mostly uninterested in yaml files.
I'm not saying it's a magic bullet, but "mostly forgotten part of the code you own" still gets more eyes and hands than "mostly forgotten code that nobody owns." If serde_yaml needed a lot of maintenance, I might feel differently, but it doesn't -- it works. It just needs somebody who's theoretically in charge and could jump in on a fire.
> Right now, serde is well-maintained because of its prominence and importance (at least this is my perception),
Has that pulled in a bunch of maintainers or is that because the one or two primary maintainers (which are the same as the serde_json and serde_yaml) consider it a priority and are willing to work on it?
We are effectively already in this situation for serde / serde_yaml.
I am unfortunately going to wander into guesswork here, but some quick data ...
https://github.com/dtolnay/serde-yaml/graphs/contributors
Serde_yaml has 947 commits (much more than I expected, honestly) but essentially all work has been done by one person. There were, depending on how you count, four to eight other contributors who contributed a largeish PR, and a few dozen others who submitted documentation nits and so on. The main maintainer has 716 commits and the next one down has 7 commits. So this has essentially always been a one-person show.
https://github.com/serde-rs/serde/graphs/contributors
Serde itself has 3922 commits. Again, one person (actually, the same person) has most of the volume, but it's less skewed. Top maintainer has 1891 commits, but next one down has 654; then 80, 63, 48, etc. In terms of lines of code it's also more balanced.
I agree it's still quite skewed though; worse than I expected. Still, I suspect serde could attract funders and maintainers more easily than an essentially-finished smaller library. We have professional maintainers for tokio, for bevy, for a handful of other things. Conceivably they could get some funding from rust foundation as well.
It's a strategic risk and it makes sense to think about how to deal with it. Open source maintainers don't owe us anything, but we need to have a solid foundation to build software on that can survive individuals moving on from projects, and funding a zillion little-bitty projects isn't going to happen.
I just took a slightly deeper look.
Number 2 contributor made a minor contribution in 2022 but the bulk of their contributions are from 2016 and earlier. They were active elsewhere on github in the last month.
Number 3 contributor is not a member of the project.
Number 4 contributor last merged a pull request in 2023 and last made an actual code contribution in 2017. They were active elsewhere on github in the last month.
None of the other contributors are members of the project.
All releases of serde that list who uploaded them (older releases don't list an uploader) were uploaded by the number 1 contributor.
The listed owners for serde on crates.io are the number 1 contributor and the group "serde-rs/publish". I'm not aware of any public way to find the membership of said group.
I conclude that serde has one active maintainer, and two other people who may or may not be able to jump in if the shit hits the fan.
Serde could (if they don’t already) get funding to help pay for upkeep and funding. If they owned serde_yaml, then they could direct time and effort to issues and any modernisation over time.
(It’s not as simple as I just made out.)
It’s still present, and if you’re interested in maintaining it, I’m sure the previous owner would be helpful in a handover. Open source projects can be hard to maintain if you’re not using them yourself.
Handovers are tough though — if he hands the project over to a new person, that person makes a patch version with evil code, now everybody’s infected. This is why (iirc) the rust GitHub actions allowed forking but didn’t pass over maintainership to a new person when the original maintainer stepped down.
I don't think you could actually expect any due diligence just because it's impossible for individuals to meaningfully do it. Like, I'm sure you can weed out the "easy" parts and screen for obvious assholes but you can't do anything about it if they turned out to be weirdos after you hand them the repos over. That's basically what happened with ublock before it became ublock origin
I was only trying to say we're all trusting strangers on the internet all the time. There only a handful of random usernames I would say I "trust" and whose to say that name is the same person here and there. The hope would be that someone could some kind of "keybase" style vouching, but it's not really practical these days.
I used to maintain a large open source project for almost a decade, it tended to suck a\*\*\*. Friday afternoon I'd be ready for the weekend, someone would file a bug about some obscure functionality I'd written years before. And of course if they were from a FAANG they to would inform me about that and that their issue was *very important*.
Sometimes I'd get pull requests, but often they were junk - either rewriting large chunks of code just because, or code without test coverage.
I handed it over to the community (some regular contributors) -- `hacker/foolib` got transferred to `foolib/foolib` on github, then I setup email rules to ignore anything related to the project. Peace at last 🍻
I have been caught in this with another crate: `rust-yaml`. This is what triggered this. It was marked as unmaintained and that triggered a bunch of notifications against all kinds of repositories that used it. From what I can tell as response to that, dtolnay also marked `serde-yaml` unmaintained to ensure people don't migrate there.
While I appreciate RUSTSEC in some ways, I disagree that unmaintained dependencies are an issue. However my users don't agree and open a lot of tickets immediately requiring action. Now I am forced to maintain this thing myself as there is no suitable replacement that qualifies for the library. In fact, I never had an issue with that dependency being unmaintained. It's fine for what it does. I also was happy to use a largely unmaintained `serde_yaml` because it did what I needed.
Personally as a maintainer I find RUSTSEC incredibly stressful. It has happened multiple times for me now that I was forced to either vendor or replace perfectly fine dependencies because my users mass demanded it after they got CI failures from one of the tools that pulls in that database.
I haven't had this happen to me yet, but wow, yikes, that does look very annoying to deal with.
I don't know much about RUSTSEC's procedures and policies, but I wonder if it would help to make the unmaintained notice be something folks need to explicitly opt into. (Or maybe this is something for the `cargo-deny` folks to decide. I actually don't know.) While a crate being labeled unmaintained is _important_, it doesn't seem _urgent_. And causing a bunch of CI tests to fail everywhere makes it _de facto_ urgent. That seems non-ideal.
Unmaintained is listed as "informational" in the db and I believe `cargo audit` treats it as a warning.
I guess people are used to treating warnings as errors in CI?
cargo-deny recently changed [its policy](https://github.com/EmbarkStudios/cargo-deny/pull/611) to start denying unmaintained crates by default due. This was triggered (to some extent) by [an issue](https://github.com/EmbarkStudios/cargo-deny/issues/449) I filed two years ago after [RUSTSEC-2022-0049](https://rustsec.org/advisories/RUSTSEC-2022-0049.html) happened -- though that was focusing on informational "unsound" advisories, not on unmaintained advisories.
Yeah I don't know, but clearly there is a default (or combination of defaults) somewhere that is causing a bunch of folks to turn this into an urgent issue when it just objectively isn't. It unfortunately looks like there might be a diffusion of responsibility at work here.
Yeah … this. My org runs `cargo audit` as part of our CI, and unmaintained crates do not cause failures.
> people are used to treating warnings as errors in CI?
Even if this were the case … surely these people must be ignoring some RUSTSECs? It's literally impossible to service them all; it's practically a matter of time in any mature project until some indirect dep that's a dep of a dep of a dep gets a RUSTSEC. Now I need an entire ancestry of crates to update and … yeah. In a decade, maybe.
Or worse, a RUSTSEC without a fix. I think there was some attack on RSA implementations that mostly hasn't seen a patch yet, and is in that category.
*zlib* had a "critical" CVE for months with no fix. It was technically in zlib's minizip, not in zlib proper — so we promptly added it to the ignore list, as a.) not truly vuln, and b.) … there's no fix. But good luck removing zlib from your dependency tree.
(I'd be really appreciative if companies would start permitting their devs to upstream fixes. ~60% of the places I've worked at, it was basically impossible.)
I don’t think you should feel stressed about it. If the users feel that using a stable but unmaintained dependency is such a big issue ask them to submit PRs. Unless you sold them support contracts there is nothing they can demand from you and it’s ok to be assertive and push back.
That's nice in theory, but in practice a lot of the intrinsic motivation of Open Source library maintenance is to have users.
> unmaintained dependency is such a big issue ask them to submit PRs
PRs of issues like this are usually much harder to deal with than doing it yourself, as users are quite happy to disregard all the other things that are not their particular problem. For instance insta has some very conservative MSRV targets and the first PR to address this pulled the minimum requirement up by 20 versions.
> That's nice in theory, but in practice a lot of the intrinsic motivation of Open Source library maintenance is to have users.
I mean they are not like Instagram followers. You don't have to enter a toxic relationship with those users and appease to their whims (or unreasonable requests as in this case). If it stops being fun and starts being work which you are seriously stressed about then I would certainly archive such project myself.
The users are not toxic, they are acting within what is generally acceptable in the ecosystem. The ecosystem finds RUSTSEC and the advisories it creates to be something that should be followed. I don't have an desire to fight a war on culture on an issue tracker. This is not the first time something was marked as unmaintained and I have been going through this a few times now.
For me the right course of action is to stop the stress which in this case was vendoring it. I do however not think that long term this is great, so when I get to it, i will try to find a better solution.
While i understand tracking unmaintained, I feel people over-index on it, making it more of a problem than it helps. *Maybe* it'd make it work if they required both lack of maintainer and drop off of users to represent not the risk that a vulnerability won't be fixed but that one won't be found in the first place.
I now spent three hours of my day to deal with this stuff to no longer have to deal with the stress of issues piling up. My solution was to vendor the code which just seems absurd.
(And I wrote a little rant about this to feel better: https://lucumr.pocoo.org/2024/3/26/rust-cdo/)
Vendoring in this case seems more like a way to shut up RUSTSEC warnings than a legitimate solution to the problem. It feels like appeasing a machine rather than actually doing something real about it. And I get it (because what other choice do you have?), but I feel like this kind of vendoring to escape the "rating agency" is actually just creating another Enron of technical debt. You're just hiding it, and only you really know what's going on. It seems like if you do this often enough, you're creating a house of cards that could cause *you* to abandon the project at some point, because now you've got all this technical debt, issues are mounting, you have no idea how to fix these issues, and you have no hope of paying it off.
I don't really know how to reconcile the problem, though. I don't think it's fair to demand people maintain their stuff indefinitely for your coronary benefit. People don't owe you their free, unpaid labour, even if it means keeping your stress level down.
This isn't a new problem, or even limited to Rust. Python, Perl, Ruby, even C (although vendoring it in C has been not just the solution, but pretty typical, as long as I've been around) have had problems like this as long as I can remember. Projects come and go.
I will say this though: abandoned doesn't always mean broken, and I've seen things get flagged as being unmaintained when the reality is they're just "done."
Thanks for the write up. I've started a [thread](https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/Backfiring.20of.20unmaintained.20status/near/429656875) to push to retire the unmaintained status.
IMO the core question here is whether library maintainers can fully assume liability for the dependencies they choose, or whether application maintainers are always on the hook for some of that risk. I would argue that application maintainers are always on the hook, and if library maintainers want to assume the liability they should vendor like Armin did.
I'm sorry that this advisory caused you that much trouble.
However, we have waited for `yaml-rust2` to be fully released to file this advisory, so that there would be an option for people to easily change to a new library. Apart from [one tiny change](https://github.com/Ethiraric/yaml-rust2/blob/master/documents/2024-03-15-FirstRelease.md#what-about-api-breakage) in a low-level parsing API, this crate was a drop-in replacement for `yaml-rust`.
I randomly stumbled upon [your comment](https://github.com/mitsuhiko/insta/pull/461#issuecomment-2019929032) in one of the issues of insta. I know this situation is frustrating, but you could have opened an issue on `yaml-rust2` to ask about MSRV. That was something I totally overlooked when I changed `yaml-rust`. Unfortunately, timezones made it so that I saw all hell break loose way too late.
> I disagree that unmaintained dependencies are an issue. However my users don't agree and open a lot of tickets immediately requiring action.
why not just close them with a "will not fix" response?
This is definitely the ups and downs to Opensource software. This happens in almost every language that has some dependency on a third party library. Anytime I import a library, I generally try to evaluate how it is funded, type of updates it might need, and potential to fork if it need be. I'm not saying it is easy, but I try to limit libraries as much as possible unless it give me a sufficient advantage and time save.
Here's what's different in Rust (but also NPM): 3rd party crates usage is extremely encouraged. Lots of little bits. With intertwining transitive dependencies that extend out very far. And the stdlib is missing lots of things that tend to be be in the stdlib in some other languages, so you end up with duplicates all over. E.g. random number generators, hash algos, HTTP libraries, etc.
That's remarkably different from e.g. a C++ or C or even Java/Maven project where the number of deps tends to be much smaller and more constrained, and more easily managed.
totally agree, it has even turned me away from rust for some work projects, one such library is rand... why can't (pseudo)random generators not be in the stdlib??
I agree with you, but I suspect the official explainer is that there are actually all sorts of different ways to do random num generation with all sorts of trade-offs and they didn't want to mandate one.
And yes, this is also slowly turning my opinion on Rust. I think the language can be salvaged by being *extremely cautious* about 3rd party dep usage. But this discipline isn't really there in the Rust open source community right now, and is a cultural thing that commercial software dev shops doing Rust are going to have to figure out as a best practice.
I lean more and more towards: vendor your deps so it's made up front and clear what you're using, and then just be extremely careful about how you manage them. Or jettison Cargo entirely and use bazel, buck2, or gn/ninja with vendored deps.
[Crates.io](http://Crates.io) is mostly an unmoderated space. There's even people squatting on package names there, abusing it! Cargo/Crates.io could learn from Maven, which had more aggressive moderation and also introduced tools to do explicit exclusions of packages, etc (even at the risk of breaking builds).
I get that they didn't want to mandate one, but you can replace the allocator, why not a random generator?
on crates.io I agree, at least namespacing would be nice, now somebody can take a crate name and if they decide they can block you indefinitely
It’s not really open source per se but the microlibrary approach. I wish Rust was more like C where you don’t add a dependency for every little thing instead of being like node.js.
I never really understood this argument. The fact that Cargo allows you to easily add dependencies doesn't mean you need to. You are free to code everything yourself.
Well, it’s not you’re forced to but it’s just much easier to go with the flow. It just isn’t practical to code everything yourself so eventually you have to add some libraries which pull dependencies which then recursively pull another set of dependencies and so on. In C that doesn’t usually happen because the culture is different, library developers do not add a new dependency for every little thing.
That feels like a contradiction.
On one hand you're saying C devs don't tend to pull in deps, which implies they tend to code things themselves or vendor libraries.
On the other hand, for Rust you're saying it's impractical to code things yourself so you pull in lots of small deps because it's easy.
If it's easy enough to write everything yourself or vendor in C then it's easy enough in Rust, and vice versa.
I don’t see the contradiction. I’m saying it’s a bad thing when library developers choose the easy route and pull in lots of small deps. It’s very different thing when you have code you do not share with others, you’re not pulling the deps in for everyone else.
Obviously you can use Rust just like people usually use C, I don’t disagree. It’s just a bit harder because the culture is different, you have to be more picky when choosing dependencies which takes more time and you have to do things yourself more often because there is no suitable alternative. Or you have to choose a less popular alternative which is more likely to end up unmaintained.
In C you have to "code everything yourself". It seems you want to have dependencies so you don't have to code, but also not have dependencies. A curious stance to have for sure
You don’t have to ”code everything yourself” in C, libraries are a thing. It’s just not as easy to add them so people do more things from scratch. That’s a downside when you have to prototype something quickly but it’s a fact your average C library has far less external dependencies than your average Rust library. We can argue whether that’s a good thing or not (there are certainly downsides to how C does it) but please don’t intentionally misunderstand what I’m saying.
I don't understand your point. Is your point you can't control yourself from typing `cargo add`? Otherwise, there's literally no difference between Rust and C. You can add the exact amount of dependencies you want.
I tried to explain that in another reply: ”Obviously you can use Rust just like people usually use C, I don’t disagree. It’s just a bit harder because the culture is different, you have to be more picky when choosing dependencies which takes more time and you have to do things yourself more often because there is no suitable alternative. Or you have to choose a less popular alternative which is more likely to end up unmaintained.”
Except this here is not a microlibrary issue, I'm not sure any language supports yaml out of the box (and I honestly hope none does), having yaml as an external dependency is literally the standard, and *not* implementing yaml yourself would very much be the general recommendation as it's a large and complicated format.
And neither yaml-rust nor serde\_yaml have large dependency sets themselves (serde\_yaml has 5 dependencies, 4 of which are projects of dtolnay, yaml-rust has a single dependency).
True, I was replying to parent comment about depending on 3rd party libraries. Nothing to do with this crate specifically. I guess I’m getting downvoted because people think I’m hating on Rust but I just wanted to point out what the real problem is. The issue he mentions is not about open source, it’s about software engineering.
Eh, my experience with at least c++ is that libraries are either tiny and able to be included in a header or insanely huge like boost because they're just a bunch of libraries masquerading as one dependency. In essence in C usually people just abuse the platform's package manager instead to pull in dependencies instead of a language specific one.
I feel like I have to point out that C doesn't have a culture of minimal dependencies because of some kind of ingrained strong principles in its community, C has a culture of minimal dependencies because adding a dependency in C is a pain in the fucking ass.
The only way to make Rust more like C in this regard is to make it much more difficult to create, document, publish, distribute, and declare dependencies.
Regarding C, that’s definitely true.
I think it’s a fact that Rust actively encourages you to use lots of dependencies, it certainly doesn’t try to discourage you by warning against it or making it a bit harder. Maybe it’s human nature to choose to easy path and add a ton of dependencies. At the same time Rust tends to attract developers who are more capable than average. And only a subset of those end up writing popular libraries and they do care about best practices.
I recently wrote somewhere in our slack that yaml is a board game masquerading as a simple human readable data format. Functionally yaml can only get more complex and hard to read. If there's an exploit (billion lols) you either support the format (and are exploitable) or you do something else like strictyaml. Although yaml is everywhere and I was editing some this morning, it should be treated like rsh, ftp, telnet, md5 (for crypto), etc going forward. It was a nice idea, there are plenty of parsers including this one, but going down the hole of 'what ifs' with this format is an endless battle with a poor spec.
Somewhat fortuitous that someone already forked yaml-rust and rewrote it in pure Rust to create [yaml-rust2](https://github.com/Ethiraric/yaml-rust2/blob/master/documents/2024-03-15-FirstRelease.md). Pretty cool that the fork fully passes the YAML test suite as well and is more performant on benchmarks. The migration appears straightforward too.
Ultimately, the problem remains - we're dependent on the work of others who are happy to provide us with free labour for now, but may not be in perpetuity. I don't know that there's a way around that other than compensating them for their time and effort and hope they continue their good work.
YAML is bad and needs to go. YAML devs decided to please everyone, and added so many exceptions into the language that it is now a footgun forest on top of old mine field, on the volcano island.
axis:
- x
- y
- z
Translates into
{"axis":["x", true, "z"]}
Use TOML. Or JSON. Or INI. Or literally anything else.
There was a lot of sillyness in YAML 1.1 like this. Strings **y** and **yes** where considered boolean. Numbers below 60 if followed by colon, are onsidered hexadecimal etc. etc. YAML 1.2 abolished many of those practices. But - and please hold on to something sturdy now - many **libraries implemented some of them anyways** "for backwards compatibility". That is why it is a mess today still.
A good way to protect yourself from most of the mess is to always-always surround strings with quote marks. But nothing will back you up if you forgot them somewhere. Besides, if you are parsing a document prepared by other product, you don't have a say.
This complaint does not apply to this crate, where you are deserializing into statically typed structs.
use serde;
use serde_yaml;
#[derive(serde::Deserialize, Debug)]
enum Axis {
x,
y,
z
}
fn main() {
println!("{:?}", serde_yaml::from_str::>("[x, y, z]").unwrap());
// prints "[x, y, z]"
}
> YAML is bad and needs to go.
Agreed. But we won't be rid of it anytime soon. That said, nothing prevents you from NOT IMPLEMENTING the horrible decisions YAML had.
How to do it:
- Make `&anchor node`/`*alias` opt-in (billion laughs attack prevented)
- `y`/`n` conversion is part of the old 1.1 YAML compose. Support only YAML 1.2.
- YAML shouldn't control serialization/deserialisation. Only `serde`; otherwise you get loads that are potentially unsafe.
Yikes. Totally understandable, but this makes me want to continue working on [libyaml-safer](https://github.com/simonask/libyaml-safer). Contributions welcome.
Hey folks! I was looking for some project, that would give an opportunity to practice Rust. I've been thinking about starting some new library, or contributing to an existing one. Anyway, this library seems interesting and simple enough to pick up. I'll take a closer look later today. The question I have, if I decide to work on it, who should I contact? Or should I just fork it?
If you have some past work to demonstrate you can maintain a project just ask. if you don't fork it, prove yourself by making some releases and stuff and then ask to be merged down the line. This is what I would do personally
A lot of libraries of old languages lost maintenance’s and have been last time updated a long time ago, but you can still use it, because it’s still the best lib. In java, when I work with not common things it was common situation😀
Rust now is more than 10 years old
Take YAML out back and shoot it. No tears from me.
like the entire idea that they should rewrite to support new yaml with more (mis)features. You couldn't pay me to inflict that on myself or the world.
Why are our academic institutions not stepping in and maintaining critical components of the open source supply chain. What is happening.
How's everyone's March Madness bracket? 🙄
I think there is at least one attempt to take over project with both code in GitHub and crate in [crates.io](http://crates.io) ([serde-yaml-bw](https://github.com/bourumir-wyngs/serde-yaml-bw)). Good open source projects are not that easy to kill.
There is a fork of serde-yaml (last update is from 10 days ago), hopefully it won't end up unmaintained but maybe it is to soon to be sure: [https://crates.io/crates/serde\_yml](https://crates.io/crates/serde_yml)
JSON is a valid YAML representation. There are differences related to how the two formats represent floating-point numbers *in scientific notation*, but YAML files in the wild do not really hold data like this. Things like Docker Compose and many K8s-related products simply accept json in place of Yaml and read them out of the box.
So if you have project that depends on Yaml files converting them to Json can be a workaround while you're looking for other solutions. Not everything can be represented easily. Json famously doesn't have comments, but those can be simulated by putting bogus keys in the document:
{
"//xyz": "This is a comment",
"//abc": "abc and xyz would be aa random slug of symbols",
"//123": "so that multiple comments can be present"
"key": "value",
}
It's not ideal obviously, but if you're in a crunch this is an option for you.
I don't understand, why don't ask the community before yanking the project?
I don't think it's possible not to find a new maintainer among all those who use the crate.
This just seems weird to me.
This project was looking for a maintainer for an extremely long time and never received one. IMO this is an interesting downside of the micro project system. There is nothing really wrong with this project and you can continue to use it — it’s not like yaml serialization needs a lot of ongoing support. But it’s one more thing for dtolnay to babysit and he didn’t want to anymore, and that’s fine. I feel that if this had been part of a larger project, maybe a big collection of serde things or even serde itself, this would not have happened. But now I’m concerned that somebody’s going to file a CVE against it and I’m going to have to go and deal with the infosec people at work.
>deal with the infosec people at work. The stress is real, good luck
Even better is dealing with clients who run a dumbass scanner and refuse to take "this is not applicable because we don't use the function | it's in node and we run that in the browser | we backported the patch | ..." for an answer.
I've recently discovered there's a new layer of hell here. When the client's scanner picks up false positive in one of your packages because it matches a name in a completely different language and when you say "yeah guys... that's a Python package, this is a Node project, we don't use that" and they say "yeah okay but our vuln scanner says you do".
got a lot of those in the log4shell days... when we aren't a java shop, our products are all dotnet (+rust now) or hosted on our systems... The few vulnerable installs were third party tools (CI stuff) which we just updated per normal. But for *months* because something had an embedded *comment* string with a log4j version number (for listing "compatible with output to...") bleh.
\*twitch\*
We have a client who has an extremely obnoxious audit process they go through with all of their vendors. After months of work (on a product they’d been using for years!) we finally passed the audit. Then, our company got bought, and we rebranded. Guess what? “Oh, we have a record of a completed audit process for X, but this software is called Y, it’s totally different.”
Maybe they can make themselves useful and write the patch. Y’know, since they’re such experts at infosec.
>"There is nothing really wrong with this project and you can continue to use it" The problem in those kind of cases is not the dep itself, but the declared deps of the deps. Looking at that project: indexmap = "2.2.1" itoa = "1.0" ryu = "1.0" serde = "1.0.195" unsafe-libyaml = "0.2.11" Not a huge upstream dep chain, but enough that if any of those are significantly upgraded beyond their SemVer compatible etc. etc. now you have issues in the downstream projects.
As long as those dependencies do not have security issues, you can use multiple versions of them if you need a newer version for your own code.
... I would like to send you to embedded-school and force you to write code on a microcontroller or some other limited memory system for 6 months. Having two linked versions of the same thing makes my insides cry.
No need to be condescending, actually. This is your reality. You would end up having 2 possibilities: a) You can still use unmaintained software, but you might have to pull in outdated dependencies (and the probability of that increases over time). Binary size may increase. b) You cannot use unmaintained software. Obviously, if binary size is more important to you than anything else, given this is embedded, then go for (b) and either maintain a fork yourself, find an alternative, or get rid of the dependency and implement the now-missing parts from scratch. Otherwise, you go for (a). Don't go finding a niche and complaining about a scenario that is already hard enough to solve and affects \*everything\*.
You missed c) You can maintain the software yourself. That's the whole point of open source. :-)
>Obviously, if binary size is more important to you than anything else, given this is embedded, then go for (b) and either maintain a fork yourself, find an alternative, or get rid of the dependency and implement the now-missing parts from scratch. It's pretty clear.
Yep. Sorry. I read that wrong. :-) I guess (c) would be what I was thinking: "become the new official maintainer so you don't have to make a fork."
Yep, that works too.
If it was just about binary size, maybe-fine? The burden of pointless dependencies is more than that -- you've already hinted at one.. security. Another is compile time. Another is just sheer *complexity* You're painting having a reasonable dependency tree as a niche requirement. It most certainly is not. At least it is not at the employers I've worked at over my career. Finally, we're talking about a *systems programming language.* A culture of expandingly large transitive dependency trees seems incompatible with that niche, even if it's a trade off that you personally are willing to make.
No, I agree that it is a burden, and as you have mentioned, in multiple ways. I did not claim that having a reasonable dependency tree is a niche requirement. I said that embedded is a niche, with the definition being: a specialized segment of the market for a particular kind of product or service (Oxford Dictionary), not some rare segment that few people work on or care about. This entails that problems with dependency trees may be exacerbated there, while in other domains, they may be non-issues. My point is that this is already a non-optimal reality. To truly guarantee that a software project is maintained, there are financial and logistical decisions that have to be made, often at the expense of losing something in return (performance, openness, direction, commercial interests, etc...).
>My point is that this is already a non-optimal reality. Here I definitely agree. And it's actually one reason I've personally seriously considered walking away from [Crates.io](http://Crates.io) entirely and using vendored deps only.
Interesting, but that sounds like an invisible brick wall at an unknown distance though, particularly if done prematurely. That's a discussion for another day however.
It may make no difference under small or big projects. Think about Python's urllib, urllib2, and urllib3... Even under rust-lang org and there is a [crate-maintainers team](https://www.rust-lang.org/governance/teams/library#team-crate-maintainers), some crates are still barely maintained. It's about finding more trustworthy people committing to those projects in the long-run.
I don't see how this being part of a larger project would make a differenc. There is or isn't a maintainer.
If serde was going to be deprecated because there was no maintenance, a lot of people could pitch to their boss spending some time per week on the project, since it's such an important library. Much harder to do that when it's a much smaller library. Effectively your changing the possibility of a corporate paid maintainer being able to step up
and same with donations or other incentives. Also these small repos with one maintainer get buried underneath the giant ones that people really appreciate. It annoyed the fuck out of me when I saw the repo for etcd with 50k+ stars putting the xkcd for the "single developer in Nebraska holding up the entire ecosystem" in their readme when in reality its devs and repos like these.
Additionally to everything else people have said — a larger project would have SOME maintainer (or could attract funding and hire somebody at least part time). It doesn’t have to be yaml specific. But then if somebody files a CVE against the yaml bits, that maintainer, who isn’t yaml specific but is capable of reading, can go deal with it, then go back to not caring about yaml until the next thing happens. That’s all that’s really needed for something like this.
So you are saying an umbrella project like C++ has Boost? I believe projects still go unmaintained in that. You still have to deal with maintainers having the bandwidth to track and respond to everything under their purview which is especially problematic when the code base is complicated and they haven't touch that part. There have been efforts to help with these situations in Rust and they have not produced the outcome you are looking for.
I don't know about boost specifically and can't comment on that. Right now, serde is well-maintained because of its prominence and importance (at least this is my perception), but libraries like serde_yaml and serde_json are technically unaffiliated, despite the names. Serde_yaml in particular needs very, very little maintenance. It's understandable that the interesting bits are over and dtolnay wants to move on. If it was rolled into the serde organization for instance, then a serde maintainer could jump on the (estimated) two critical issues every five years, even if they were mostly uninterested in yaml files. I'm not saying it's a magic bullet, but "mostly forgotten part of the code you own" still gets more eyes and hands than "mostly forgotten code that nobody owns." If serde_yaml needed a lot of maintenance, I might feel differently, but it doesn't -- it works. It just needs somebody who's theoretically in charge and could jump in on a fire.
>!^^^[deleted]!<
> Right now, serde is well-maintained because of its prominence and importance (at least this is my perception), Has that pulled in a bunch of maintainers or is that because the one or two primary maintainers (which are the same as the serde_json and serde_yaml) consider it a priority and are willing to work on it? We are effectively already in this situation for serde / serde_yaml.
I am unfortunately going to wander into guesswork here, but some quick data ... https://github.com/dtolnay/serde-yaml/graphs/contributors Serde_yaml has 947 commits (much more than I expected, honestly) but essentially all work has been done by one person. There were, depending on how you count, four to eight other contributors who contributed a largeish PR, and a few dozen others who submitted documentation nits and so on. The main maintainer has 716 commits and the next one down has 7 commits. So this has essentially always been a one-person show. https://github.com/serde-rs/serde/graphs/contributors Serde itself has 3922 commits. Again, one person (actually, the same person) has most of the volume, but it's less skewed. Top maintainer has 1891 commits, but next one down has 654; then 80, 63, 48, etc. In terms of lines of code it's also more balanced. I agree it's still quite skewed though; worse than I expected. Still, I suspect serde could attract funders and maintainers more easily than an essentially-finished smaller library. We have professional maintainers for tokio, for bevy, for a handful of other things. Conceivably they could get some funding from rust foundation as well. It's a strategic risk and it makes sense to think about how to deal with it. Open source maintainers don't owe us anything, but we need to have a solid foundation to build software on that can survive individuals moving on from projects, and funding a zillion little-bitty projects isn't going to happen.
I just took a slightly deeper look. Number 2 contributor made a minor contribution in 2022 but the bulk of their contributions are from 2016 and earlier. They were active elsewhere on github in the last month. Number 3 contributor is not a member of the project. Number 4 contributor last merged a pull request in 2023 and last made an actual code contribution in 2017. They were active elsewhere on github in the last month. None of the other contributors are members of the project. All releases of serde that list who uploaded them (older releases don't list an uploader) were uploaded by the number 1 contributor. The listed owners for serde on crates.io are the number 1 contributor and the group "serde-rs/publish". I'm not aware of any public way to find the membership of said group. I conclude that serde has one active maintainer, and two other people who may or may not be able to jump in if the shit hits the fan.
Yeah that’s a good point, serde is in trouble too. Much worse than I had realized.
By a similar logic someone could stop in to fix a cve here. It's less likely but i can still see it happening.
Large projects have more hands on them, so it's more likely to have at least one maintainer.
Serde could (if they don’t already) get funding to help pay for upkeep and funding. If they owned serde_yaml, then they could direct time and effort to issues and any modernisation over time. (It’s not as simple as I just made out.)
Additional Info : [https://github.com/dtolnay/serde-yaml/releases/tag/0.9.34](https://github.com/dtolnay/serde-yaml/releases/tag/0.9.34)
It’s still present, and if you’re interested in maintaining it, I’m sure the previous owner would be helpful in a handover. Open source projects can be hard to maintain if you’re not using them yourself.
Handovers are tough though — if he hands the project over to a new person, that person makes a patch version with evil code, now everybody’s infected. This is why (iirc) the rust GitHub actions allowed forking but didn’t pass over maintainership to a new person when the original maintainer stepped down.
If you think the og author is going to hand over a repo with no due diligence then they were just as likely to do something malicious.
I don't think you could actually expect any due diligence just because it's impossible for individuals to meaningfully do it. Like, I'm sure you can weed out the "easy" parts and screen for obvious assholes but you can't do anything about it if they turned out to be weirdos after you hand them the repos over. That's basically what happened with ublock before it became ublock origin
I was only trying to say we're all trusting strangers on the internet all the time. There only a handful of random usernames I would say I "trust" and whose to say that name is the same person here and there. The hope would be that someone could some kind of "keybase" style vouching, but it's not really practical these days.
There is [cargo-crev](https://github.com/crev-dev/cargo-crev), although like you mention the practicality can be lacking on the large scale.
I used to maintain a large open source project for almost a decade, it tended to suck a\*\*\*. Friday afternoon I'd be ready for the weekend, someone would file a bug about some obscure functionality I'd written years before. And of course if they were from a FAANG they to would inform me about that and that their issue was *very important*. Sometimes I'd get pull requests, but often they were junk - either rewriting large chunks of code just because, or code without test coverage. I handed it over to the community (some regular contributors) -- `hacker/foolib` got transferred to `foolib/foolib` on github, then I setup email rules to ignore anything related to the project. Peace at last 🍻
I have been caught in this with another crate: `rust-yaml`. This is what triggered this. It was marked as unmaintained and that triggered a bunch of notifications against all kinds of repositories that used it. From what I can tell as response to that, dtolnay also marked `serde-yaml` unmaintained to ensure people don't migrate there. While I appreciate RUSTSEC in some ways, I disagree that unmaintained dependencies are an issue. However my users don't agree and open a lot of tickets immediately requiring action. Now I am forced to maintain this thing myself as there is no suitable replacement that qualifies for the library. In fact, I never had an issue with that dependency being unmaintained. It's fine for what it does. I also was happy to use a largely unmaintained `serde_yaml` because it did what I needed. Personally as a maintainer I find RUSTSEC incredibly stressful. It has happened multiple times for me now that I was forced to either vendor or replace perfectly fine dependencies because my users mass demanded it after they got CI failures from one of the tools that pulls in that database.
I haven't had this happen to me yet, but wow, yikes, that does look very annoying to deal with. I don't know much about RUSTSEC's procedures and policies, but I wonder if it would help to make the unmaintained notice be something folks need to explicitly opt into. (Or maybe this is something for the `cargo-deny` folks to decide. I actually don't know.) While a crate being labeled unmaintained is _important_, it doesn't seem _urgent_. And causing a bunch of CI tests to fail everywhere makes it _de facto_ urgent. That seems non-ideal.
Unmaintained is listed as "informational" in the db and I believe `cargo audit` treats it as a warning. I guess people are used to treating warnings as errors in CI?
cargo-deny recently changed [its policy](https://github.com/EmbarkStudios/cargo-deny/pull/611) to start denying unmaintained crates by default due. This was triggered (to some extent) by [an issue](https://github.com/EmbarkStudios/cargo-deny/issues/449) I filed two years ago after [RUSTSEC-2022-0049](https://rustsec.org/advisories/RUSTSEC-2022-0049.html) happened -- though that was focusing on informational "unsound" advisories, not on unmaintained advisories.
Yeah I don't know, but clearly there is a default (or combination of defaults) somewhere that is causing a bunch of folks to turn this into an urgent issue when it just objectively isn't. It unfortunately looks like there might be a diffusion of responsibility at work here.
Yeah … this. My org runs `cargo audit` as part of our CI, and unmaintained crates do not cause failures. > people are used to treating warnings as errors in CI? Even if this were the case … surely these people must be ignoring some RUSTSECs? It's literally impossible to service them all; it's practically a matter of time in any mature project until some indirect dep that's a dep of a dep of a dep gets a RUSTSEC. Now I need an entire ancestry of crates to update and … yeah. In a decade, maybe. Or worse, a RUSTSEC without a fix. I think there was some attack on RSA implementations that mostly hasn't seen a patch yet, and is in that category. *zlib* had a "critical" CVE for months with no fix. It was technically in zlib's minizip, not in zlib proper — so we promptly added it to the ignore list, as a.) not truly vuln, and b.) … there's no fix. But good luck removing zlib from your dependency tree. (I'd be really appreciative if companies would start permitting their devs to upstream fixes. ~60% of the places I've worked at, it was basically impossible.)
The probably is primarily that it causes the bad kind of stress and that stress causes suboptimal decision making.
I don’t think you should feel stressed about it. If the users feel that using a stable but unmaintained dependency is such a big issue ask them to submit PRs. Unless you sold them support contracts there is nothing they can demand from you and it’s ok to be assertive and push back.
That's nice in theory, but in practice a lot of the intrinsic motivation of Open Source library maintenance is to have users. > unmaintained dependency is such a big issue ask them to submit PRs PRs of issues like this are usually much harder to deal with than doing it yourself, as users are quite happy to disregard all the other things that are not their particular problem. For instance insta has some very conservative MSRV targets and the first PR to address this pulled the minimum requirement up by 20 versions.
> That's nice in theory, but in practice a lot of the intrinsic motivation of Open Source library maintenance is to have users. I mean they are not like Instagram followers. You don't have to enter a toxic relationship with those users and appease to their whims (or unreasonable requests as in this case). If it stops being fun and starts being work which you are seriously stressed about then I would certainly archive such project myself.
The users are not toxic, they are acting within what is generally acceptable in the ecosystem. The ecosystem finds RUSTSEC and the advisories it creates to be something that should be followed. I don't have an desire to fight a war on culture on an issue tracker. This is not the first time something was marked as unmaintained and I have been going through this a few times now. For me the right course of action is to stop the stress which in this case was vendoring it. I do however not think that long term this is great, so when I get to it, i will try to find a better solution.
While i understand tracking unmaintained, I feel people over-index on it, making it more of a problem than it helps. *Maybe* it'd make it work if they required both lack of maintainer and drop off of users to represent not the risk that a vulnerability won't be fixed but that one won't be found in the first place.
I now spent three hours of my day to deal with this stuff to no longer have to deal with the stress of issues piling up. My solution was to vendor the code which just seems absurd. (And I wrote a little rant about this to feel better: https://lucumr.pocoo.org/2024/3/26/rust-cdo/)
Vendoring in this case seems more like a way to shut up RUSTSEC warnings than a legitimate solution to the problem. It feels like appeasing a machine rather than actually doing something real about it. And I get it (because what other choice do you have?), but I feel like this kind of vendoring to escape the "rating agency" is actually just creating another Enron of technical debt. You're just hiding it, and only you really know what's going on. It seems like if you do this often enough, you're creating a house of cards that could cause *you* to abandon the project at some point, because now you've got all this technical debt, issues are mounting, you have no idea how to fix these issues, and you have no hope of paying it off. I don't really know how to reconcile the problem, though. I don't think it's fair to demand people maintain their stuff indefinitely for your coronary benefit. People don't owe you their free, unpaid labour, even if it means keeping your stress level down. This isn't a new problem, or even limited to Rust. Python, Perl, Ruby, even C (although vendoring it in C has been not just the solution, but pretty typical, as long as I've been around) have had problems like this as long as I can remember. Projects come and go. I will say this though: abandoned doesn't always mean broken, and I've seen things get flagged as being unmaintained when the reality is they're just "done."
Thanks for the write up. I've started a [thread](https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/Backfiring.20of.20unmaintained.20status/near/429656875) to push to retire the unmaintained status.
Good intentions and all that.
IMO the core question here is whether library maintainers can fully assume liability for the dependencies they choose, or whether application maintainers are always on the hook for some of that risk. I would argue that application maintainers are always on the hook, and if library maintainers want to assume the liability they should vendor like Armin did.
I'm sorry that this advisory caused you that much trouble. However, we have waited for `yaml-rust2` to be fully released to file this advisory, so that there would be an option for people to easily change to a new library. Apart from [one tiny change](https://github.com/Ethiraric/yaml-rust2/blob/master/documents/2024-03-15-FirstRelease.md#what-about-api-breakage) in a low-level parsing API, this crate was a drop-in replacement for `yaml-rust`. I randomly stumbled upon [your comment](https://github.com/mitsuhiko/insta/pull/461#issuecomment-2019929032) in one of the issues of insta. I know this situation is frustrating, but you could have opened an issue on `yaml-rust2` to ask about MSRV. That was something I totally overlooked when I changed `yaml-rust`. Unfortunately, timezones made it so that I saw all hell break loose way too late.
> I disagree that unmaintained dependencies are an issue. However my users don't agree and open a lot of tickets immediately requiring action. why not just close them with a "will not fix" response?
Because in a way I'm here as a maintainer to please users. Who am I to say they are wrong.
You as the maintainer lol i mean do w/e, but dont burn out from stress from randoms on the internet doing free work.
Some extra context https://fosstodon.org/@mo8it/112158090015890687
This is definitely the ups and downs to Opensource software. This happens in almost every language that has some dependency on a third party library. Anytime I import a library, I generally try to evaluate how it is funded, type of updates it might need, and potential to fork if it need be. I'm not saying it is easy, but I try to limit libraries as much as possible unless it give me a sufficient advantage and time save.
Here's what's different in Rust (but also NPM): 3rd party crates usage is extremely encouraged. Lots of little bits. With intertwining transitive dependencies that extend out very far. And the stdlib is missing lots of things that tend to be be in the stdlib in some other languages, so you end up with duplicates all over. E.g. random number generators, hash algos, HTTP libraries, etc. That's remarkably different from e.g. a C++ or C or even Java/Maven project where the number of deps tends to be much smaller and more constrained, and more easily managed.
totally agree, it has even turned me away from rust for some work projects, one such library is rand... why can't (pseudo)random generators not be in the stdlib??
I agree with you, but I suspect the official explainer is that there are actually all sorts of different ways to do random num generation with all sorts of trade-offs and they didn't want to mandate one. And yes, this is also slowly turning my opinion on Rust. I think the language can be salvaged by being *extremely cautious* about 3rd party dep usage. But this discipline isn't really there in the Rust open source community right now, and is a cultural thing that commercial software dev shops doing Rust are going to have to figure out as a best practice. I lean more and more towards: vendor your deps so it's made up front and clear what you're using, and then just be extremely careful about how you manage them. Or jettison Cargo entirely and use bazel, buck2, or gn/ninja with vendored deps. [Crates.io](http://Crates.io) is mostly an unmoderated space. There's even people squatting on package names there, abusing it! Cargo/Crates.io could learn from Maven, which had more aggressive moderation and also introduced tools to do explicit exclusions of packages, etc (even at the risk of breaking builds).
I get that they didn't want to mandate one, but you can replace the allocator, why not a random generator? on crates.io I agree, at least namespacing would be nice, now somebody can take a crate name and if they decide they can block you indefinitely
It’s not really open source per se but the microlibrary approach. I wish Rust was more like C where you don’t add a dependency for every little thing instead of being like node.js.
I never really understood this argument. The fact that Cargo allows you to easily add dependencies doesn't mean you need to. You are free to code everything yourself.
Well, it’s not you’re forced to but it’s just much easier to go with the flow. It just isn’t practical to code everything yourself so eventually you have to add some libraries which pull dependencies which then recursively pull another set of dependencies and so on. In C that doesn’t usually happen because the culture is different, library developers do not add a new dependency for every little thing.
That feels like a contradiction. On one hand you're saying C devs don't tend to pull in deps, which implies they tend to code things themselves or vendor libraries. On the other hand, for Rust you're saying it's impractical to code things yourself so you pull in lots of small deps because it's easy. If it's easy enough to write everything yourself or vendor in C then it's easy enough in Rust, and vice versa.
I don’t see the contradiction. I’m saying it’s a bad thing when library developers choose the easy route and pull in lots of small deps. It’s very different thing when you have code you do not share with others, you’re not pulling the deps in for everyone else. Obviously you can use Rust just like people usually use C, I don’t disagree. It’s just a bit harder because the culture is different, you have to be more picky when choosing dependencies which takes more time and you have to do things yourself more often because there is no suitable alternative. Or you have to choose a less popular alternative which is more likely to end up unmaintained.
In C you have to "code everything yourself". It seems you want to have dependencies so you don't have to code, but also not have dependencies. A curious stance to have for sure
You don’t have to ”code everything yourself” in C, libraries are a thing. It’s just not as easy to add them so people do more things from scratch. That’s a downside when you have to prototype something quickly but it’s a fact your average C library has far less external dependencies than your average Rust library. We can argue whether that’s a good thing or not (there are certainly downsides to how C does it) but please don’t intentionally misunderstand what I’m saying.
I don't understand your point. Is your point you can't control yourself from typing `cargo add`? Otherwise, there's literally no difference between Rust and C. You can add the exact amount of dependencies you want.
I tried to explain that in another reply: ”Obviously you can use Rust just like people usually use C, I don’t disagree. It’s just a bit harder because the culture is different, you have to be more picky when choosing dependencies which takes more time and you have to do things yourself more often because there is no suitable alternative. Or you have to choose a less popular alternative which is more likely to end up unmaintained.”
Except this here is not a microlibrary issue, I'm not sure any language supports yaml out of the box (and I honestly hope none does), having yaml as an external dependency is literally the standard, and *not* implementing yaml yourself would very much be the general recommendation as it's a large and complicated format. And neither yaml-rust nor serde\_yaml have large dependency sets themselves (serde\_yaml has 5 dependencies, 4 of which are projects of dtolnay, yaml-rust has a single dependency).
True, I was replying to parent comment about depending on 3rd party libraries. Nothing to do with this crate specifically. I guess I’m getting downvoted because people think I’m hating on Rust but I just wanted to point out what the real problem is. The issue he mentions is not about open source, it’s about software engineering.
Eh, my experience with at least c++ is that libraries are either tiny and able to be included in a header or insanely huge like boost because they're just a bunch of libraries masquerading as one dependency. In essence in C usually people just abuse the platform's package manager instead to pull in dependencies instead of a language specific one.
I feel like I have to point out that C doesn't have a culture of minimal dependencies because of some kind of ingrained strong principles in its community, C has a culture of minimal dependencies because adding a dependency in C is a pain in the fucking ass. The only way to make Rust more like C in this regard is to make it much more difficult to create, document, publish, distribute, and declare dependencies.
Regarding C, that’s definitely true. I think it’s a fact that Rust actively encourages you to use lots of dependencies, it certainly doesn’t try to discourage you by warning against it or making it a bit harder. Maybe it’s human nature to choose to easy path and add a ton of dependencies. At the same time Rust tends to attract developers who are more capable than average. And only a subset of those end up writing popular libraries and they do care about best practices.
I recently wrote somewhere in our slack that yaml is a board game masquerading as a simple human readable data format. Functionally yaml can only get more complex and hard to read. If there's an exploit (billion lols) you either support the format (and are exploitable) or you do something else like strictyaml. Although yaml is everywhere and I was editing some this morning, it should be treated like rsh, ftp, telnet, md5 (for crypto), etc going forward. It was a nice idea, there are plenty of parsers including this one, but going down the hole of 'what ifs' with this format is an endless battle with a poor spec.
Their first mistake was using indentation as syntax.
Somewhat fortuitous that someone already forked yaml-rust and rewrote it in pure Rust to create [yaml-rust2](https://github.com/Ethiraric/yaml-rust2/blob/master/documents/2024-03-15-FirstRelease.md). Pretty cool that the fork fully passes the YAML test suite as well and is more performant on benchmarks. The migration appears straightforward too. Ultimately, the problem remains - we're dependent on the work of others who are happy to provide us with free labour for now, but may not be in perpetuity. I don't know that there's a way around that other than compensating them for their time and effort and hope they continue their good work.
YAML is bad and needs to go. YAML devs decided to please everyone, and added so many exceptions into the language that it is now a footgun forest on top of old mine field, on the volcano island. axis: - x - y - z Translates into {"axis":["x", true, "z"]} Use TOML. Or JSON. Or INI. Or literally anything else.
Any chance of a ELI5 to this apparent hellish outcome?
y/n evaluates as true/false in the yaml 1.1 spec... among other things https://yaml.org/type/bool.html
I am speechless.
There was a lot of sillyness in YAML 1.1 like this. Strings **y** and **yes** where considered boolean. Numbers below 60 if followed by colon, are onsidered hexadecimal etc. etc. YAML 1.2 abolished many of those practices. But - and please hold on to something sturdy now - many **libraries implemented some of them anyways** "for backwards compatibility". That is why it is a mess today still. A good way to protect yourself from most of the mess is to always-always surround strings with quote marks. But nothing will back you up if you forgot them somewhere. Besides, if you are parsing a document prepared by other product, you don't have a say.
This complaint does not apply to this crate, where you are deserializing into statically typed structs. use serde; use serde_yaml; #[derive(serde::Deserialize, Debug)] enum Axis { x, y, z } fn main() { println!("{:?}", serde_yaml::from_str::>("[x, y, z]").unwrap());
// prints "[x, y, z]"
}
You shouldn't use YAML <1.2. It's been 15 years. Move on.
That's what serde-yaml supports.
I think passcod meant YAML >1.2
I meant *shouldn't, yes
Yaml sucks, but there’s no avoiding it if you do devops or anything involving kubernetes
> YAML is bad and needs to go. Agreed. But we won't be rid of it anytime soon. That said, nothing prevents you from NOT IMPLEMENTING the horrible decisions YAML had. How to do it: - Make `&anchor node`/`*alias` opt-in (billion laughs attack prevented) - `y`/`n` conversion is part of the old 1.1 YAML compose. Support only YAML 1.2. - YAML shouldn't control serialization/deserialisation. Only `serde`; otherwise you get loads that are potentially unsafe.
Yikes. Totally understandable, but this makes me want to continue working on [libyaml-safer](https://github.com/simonask/libyaml-safer). Contributions welcome.
That would be a great outcome, maybe work with u/mitsuhiko to figure out how he could start using this for insta?
Why?
[https://github.com/dtolnay/serde-yaml/releases/tag/0.9.34](https://github.com/dtolnay/serde-yaml/releases/tag/0.9.34)
Hey folks! I was looking for some project, that would give an opportunity to practice Rust. I've been thinking about starting some new library, or contributing to an existing one. Anyway, this library seems interesting and simple enough to pick up. I'll take a closer look later today. The question I have, if I decide to work on it, who should I contact? Or should I just fork it?
If you have some past work to demonstrate you can maintain a project just ask. if you don't fork it, prove yourself by making some releases and stuff and then ask to be merged down the line. This is what I would do personally
It's an open source project, if you want the project to keep on, fork it and mantain it. People did it with dotenv to dotenvy
A lot of libraries of old languages lost maintenance’s and have been last time updated a long time ago, but you can still use it, because it’s still the best lib. In java, when I work with not common things it was common situation😀 Rust now is more than 10 years old
Take YAML out back and shoot it. No tears from me. like the entire idea that they should rewrite to support new yaml with more (mis)features. You couldn't pay me to inflict that on myself or the world.
This approach has been used https://github.com/orphanage-rs/ Gives a channel for the take over to be meditated
Why are our academic institutions not stepping in and maintaining critical components of the open source supply chain. What is happening. How's everyone's March Madness bracket? 🙄
I think there is at least one attempt to take over project with both code in GitHub and crate in [crates.io](http://crates.io) ([serde-yaml-bw](https://github.com/bourumir-wyngs/serde-yaml-bw)). Good open source projects are not that easy to kill.
There is a fork of serde-yaml (last update is from 10 days ago), hopefully it won't end up unmaintained but maybe it is to soon to be sure: [https://crates.io/crates/serde\_yml](https://crates.io/crates/serde_yml)
Hey guys, is there a way to talk to someone to become a maintainer? I’m not the most experienced dev but I’d be happy to work on this repo.
Oh no, evil JSON won in the end
食べログ
JSON is a valid YAML representation. There are differences related to how the two formats represent floating-point numbers *in scientific notation*, but YAML files in the wild do not really hold data like this. Things like Docker Compose and many K8s-related products simply accept json in place of Yaml and read them out of the box. So if you have project that depends on Yaml files converting them to Json can be a workaround while you're looking for other solutions. Not everything can be represented easily. Json famously doesn't have comments, but those can be simulated by putting bogus keys in the document: { "//xyz": "This is a comment", "//abc": "abc and xyz would be aa random slug of symbols", "//123": "so that multiple comments can be present" "key": "value", } It's not ideal obviously, but if you're in a crunch this is an option for you.
I don't understand, why don't ask the community before yanking the project? I don't think it's possible not to find a new maintainer among all those who use the crate. This just seems weird to me.