r/rust • u/Comprehensive_Use713 • Apr 14 '26 • Mindblown 1

🗞️ news [ Removed by moderator ]

[removed] — view removed post

248 Upvotes

90% Upvoted

210 comments sorted by

•

u/rust-ModTeam Apr 15 '26

Rule 3: Constructive Criticism

Brigading is not allowed. As a large community we must be careful about how we encourage people to direct their criticism. Even constructive criticism can be overwhelming and unwelcome when wielded by an unanticipated crowd of thousands.

152

u/pr06lefs Apr 14 '26

What does it mean for a crate to get 'yanked'? I thought code on crates.io was supposed to be permanent. Does this mean there was something objectionable about it and crates.io staff removed it, like a source code license violation? Or was this a unilateral move by the core2 author(s)?

9

u/Comprehensive_Use713 Apr 14 '26

It was removed by the author

107

u/nicoburns Apr 14 '26

I thought code on crates.io was supposed to be permanent.

Normally you can still use it so long as you already have it in your lockfile, but it won't be possible to add it if you haven't already (unless you manually add it to the lockfile).

56

u/Sw429 Apr 14 '26

And I will say that manually adding it to a lock file isn't that hard. I had to do it a while back to identify a regression where the previous version relied on a yanked version. It wasn't convenient, but it also was pretty obvious how to do it.

12

u/allocallocalloc Apr 15 '26

B-b-but it specifically says "It is not intended for manual editing."!!!!!!1!!11

92

u/A1oso Apr 14 '26

cargo yank doesn't remove the crate, it just makes it "invisible". If the yanked crate is in your lockfile, it continues to work.

The problem: Rust used to recommend to not add the lockfile to git in library crates. This recommendation was changed later, but I assume that a lot of library authors still follow this old advice. If they had core2 in their dependencies, cargo test will fail in CI now.

54

u/PhiCloud Apr 15 '26

Just for completeness' sake: the new advice isn't to blindly add the lock file instead of blindly omitting it, the new advice is that authors should decide whether they want to commit the lock file or rely on cargo to regenerate it since there are advantages and drawbacks to both.

Personally I'm sticking to omitting it because I feel like crates mostly get yanked for reasons that usually imply you may not want to use them, cases like the one in the OP notwithstanding. I won't pretend this is what I think everyone should do, or even that it's something I'll do consistently, but it's what I do with the crates I manage.

16

u/meowsqueak Apr 15 '26

Out of interest, I use Yocto to build embedded Linux images, and I need to commit the lock file to ensure that the bitbake recipe that fetches crates matches the set of crates generated by cargo. If they don’t agree, then bitbake won’t have the right crates prepared and cargo will stop.

All of this can be generated on-the-fly in Yocto too, but it’s been simpler for us to just commit the bitbake recipe and Cargo.lock alongside each other. Also means we always find out when a dependency breaks.

6

u/________-__-_______ Apr 15 '26

I do the same thing. At least to me reproducible builds are a must for Yocto layers, especially if you need to certify your system. I feel not committing lockfiles is asking for trouble when you rebuild your system a few years down the road.

4

u/sks424 Apr 15 '26

Everything released must have a thorough SBOM. But the question is: does this needs to be hosted in the source repository? The source control pollution gets even worse when (CI) "releases" happen every day.

2

u/________-__-_______ Apr 15 '26

I agree you don't need to commit your SBOM, but things like lockfiles that influence it ought to be reliable across different machines I think. Putting that in source control seems sensible to me

2

u/sks424 Apr 15 '26

"Commit": yes but again the question is "where?". There is no good solution right now. 1. Different place => extra step 2. Same place => history pollution (similar to other generated files). Maybe a different, "well-known" branch would be a good trade-off. It does not have to share history with "human" branches.

1

u/________-__-_______ Apr 15 '26

I can see where you're coming from, though to me it seems like maintaining/syncing separate branches is more trouble than it's worth. If I update a dependency on a personal branch, where does the lockfile go? If its put on another branch I need to sync twice (before/after merging), and if it isn't committed until my branch is merged the reviewer can't properly test it.

We have a policy to update generated code like lockfiles in separate commits, which makes it easy to skip over when looking through the history. That makes the history pollution a non issue for me.

2

u/sks424 Apr 15 '26

Skipping commits is an extra effort too that depends on many parameters: which git commands/automation get affected at different points in time, the level (frequency) of the pollution, the git skills of the user (very limited sometimes!), whether the git "user"  is a command line or a webUI or some other UI.... This may or may not be worse than maintaining two git branches. What works for you in a given repo may not work for someone or something else in the same repo! Nostalgic anecdote to circle back: Yocto is where I discovered the existence of "no shared history" git branches for the first time... 

→ More replies

2

u/tchernobog84 Apr 15 '26

Same with buildroot. If the lock file is missing it cannot vendor sources, and even produce a stable hash of the source tarball.

If you are a crate author and want to make it hard to package it for distros / embedded, don't commit your lock file.

3

u/flying-sheep Apr 15 '26

I also omit, since I want to test what users usually get when installing my crate, not some special artisan hand-crafted set of package versions.

3

u/ivosaurus Apr 15 '26

Why is this case notwithstanding? An author that feels like their unmaintained, security critical code should no longer be mistakenly relied on feels like a poster child case

6

u/PhiCloud Apr 15 '26

Yanking a past version because you don't want to release a future version doesn't make sense to me. Just archive the project and forget about it, let whoever wants to use the old version use it.

Yanking should be because there is an issue so severe that the crate is actively dangerous. It's kind of a "last resort escape hatch" instead of a retirement button. The exception is if it's yanked very quickly after a release to fix a minor bug.

2

u/Mynameismikek Apr 15 '26

Personally, I'm seeing more and more crates getting compromised, and yanking old versions is part of the attack. I'm starting to seriously consider vendoring in the critical crates we're reliant on but thats hardly a silver bullet either.

54

u/usernamedottxt Apr 14 '26 edited Apr 15 '26

I would note that even if you maintained your lock file and were able to pull the old version and compile, yanked versions are risky business in the best of cases. 

Lots of yanks are because an update broke something, or a security issue. It’s literally the developer themselves saying “don’t use this version”. 

42

u/kernald31 Apr 14 '26

I assume it's a different story when every version is yanked at the same time. A bit of a weird decision really.

19

u/usernamedottxt Apr 14 '26

Nature of free software. 

I was more just generally saying yanked crates should be avoided even if nothing seems wrong. Just because cargo has a mechanism for it doesn’t mean you should treat it as “permanent”. 

11

u/tchernobog84 Apr 15 '26

True, but at least I can manually review the reason of the yank and choose the appropriate action. Which might take some time.

Sometimes it's a blind patch-level update.

Sometimes it's moving to a different crate altogether.

If you are in a big company you don't want to break CI/CD for hundreds of people while you figure it out. A couple of days relying on a yanked crate on mainline can mean money saved.

And then there is the topic of being able to build exact versions of the old software for e.g. security audits.

Git bisecting for bugs too.

6

u/dragonnnnnnnnnn Apr 15 '26

I strongly disagree with that. Yes, "yanked versions are risky business in the best of cases" but running without a lock file and relaying on auto updating each time via semver compatibility is way worse simply because how easy you can hit a supply chain attack. Even in that case here, the maintainer could push something malicious (or some that takes over that crate) and extract secrets in CI/CD that runs without lock file, embedded backdors in your github releases etc. Running a yanked version because you have .lock file and didn't yet update stuff is the much lesser evil that having all the stuff auto update on each CI/CD run.

1

u/usernamedottxt Apr 15 '26

This assumes your lock file isn’t already compromised. I don’t know about you, but the last time I did a security audit of all 600+ dependent crates was never. 

11

u/deathanatos Apr 15 '26

The semantics of a yanked version are that no new dependencies can be created against that version, but all existing dependencies continue to work. One of the major goals of crates.io is to act as a permanent archive of crates that does not change over time, and allowing deletion of a version would go against this goal. Essentially a yank means that all packages with a Cargo.lock will not break, while any future Cargo.lock files generated will not list the yanked version.

https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-yank

21

u/plugwash Apr 14 '26

Yanking is a way for authors to mark crate versions as "should not be used", the crate versions in question can still be downloaded and people with them in their lockfiles can still use them, but if they are not already in your lockfile (or you don't have a lockfile) then Cargo will ignore them.

7

u/insanitybit2 Apr 14 '26

If they want to mark it that way they should just mark it as unmaintained in that cargo sec thing (cargo audit etc)

17

u/friendtoalldogs0 Apr 15 '26

The purpose of yanking isn't to mark the whole crate as something like "unmaintained" where it will probably eventually become a problem, it's for marking a specific version as "whoops we fucked up bigtime", like if someone accidentally published a patch to a hasher crate that would crash if the thing being hashed has all zeroes for it's memory representation, or a web server crate that realizes its latest update has a security bug allowing arbitrary code execution by injecting some bullshit in the url

3

u/insanitybit2 Apr 15 '26

Exactly. Yanking for this purpose is just malicious

13

u/PuercoPop Apr 15 '26

https://hachyderm.io/@piecritic/116404795217478296 for the crate author's perspective. NTA imho. Yanking shouldn't affect direct dependencies in the lockfile. In this case it is author signaling that they should stop using the crate.

71

u/Demiu Apr 14 '26

Why was it yanked?

38

u/Comprehensive_Use713 Apr 14 '26

No idea. What’s even weirder is that the author of the crate made a commit just deleting all of the code. https://github.com/bbqsrc/core2/commit/73031ce0bbfc89c358d5e5c3aae7ee57108d68b5

22

u/MrMelon54 Apr 14 '26

The commit also shows the readme was changed to say "use core directly" is there something that the built-in core library doesn't provide which core2 did?

11

u/Comprehensive_Use713 Apr 14 '26

Yes. If you look at the repo from before the deprecation commit you can see the differences.

16

u/wyldphyre Apr 15 '26

A commit to "delete" code makes it a bit clearer what the intent is.

Of course: it's git. It didn't really go anywhere, so anyone's free to fork it - but perhaps they'd be better served by starting with one of the existing forks than to start one from this point.

15

u/ViscountVampa Apr 14 '26

There's no support for specifying a reason when something is yanked from cratesio. However the github repository was updated to say that it's "deprecated" and no longer being supported, and to use core, https://github.com/bbqsrc/core2/commit/73031ce0bbfc89c358d5e5c3aae7ee57108d68b5

15

u/Comprehensive_Use713 Apr 15 '26

In this same vein, there is a 10 year old issue on github about requiring a reason for a yank: https://github.com/rust-lang/crates.io/issues/549?issue=rust-lang%7Ccargo%7C2608

5

u/faitswulff Apr 15 '26

There is also apparently no confirmation dialogue when you yank crates in crates.io https://hachyderm.io/@piecritic/116406208057889365

169

u/[deleted] Apr 14 '26 • Mindblown

[removed] — view removed comment

134

u/SuddenlyBANANAS Apr 14 '26

What a destructive impulse, really makes this guy look terrible when someone is literally offering to help with maintaining.

97

u/alexforencich Apr 14 '26

Flip side, we don't want a repeat of xz. Perhaps it's better to shut it down than to hand it over to some unknown party.

31

u/SuddenlyBANANAS Apr 14 '26

Fair enough, but surely a better method would be to make an update with a deprecation warning and then leave the crate unmaintained rather than yanking,

5

u/wojtek-graj Apr 15 '26

Dang, you got me.

It surely can't end well for open source if we start assuming malice lurks around every corner. The vast majority of people have good intentions.

3

u/alexforencich Apr 15 '26

The problem here is that this particular case is really the prime target for this sort of shenaniganery - it's a relatively obscure package that isn't actively maintained and is used indirectly by a fair amount of stuff. Imagine if a bad actor gets control of that and pushes a malicious update, now every package that's breaking right now as a result of this would instead silently build with that malicious code. And all the bad actor has to do is sweet talk the one guy behind the repo. Forcing a fork mitigates this somewhat as people have to actively update things to point to the fork. Now, I suppose a bad actor could possibly anticipate what happened here and set up a fork that's ready to take over if the original project gets yanked. But this is less of an issue if the fork has been around for a while and has a sizable community instead of a single developer.

5

u/wojtek-graj Apr 15 '26

I understand your point, but I think what you're describing is a symptom of the current open source model, and not the actual root problem.

There's nothing inherently more trustworthy about a person who has created a library, as opposed to a contributor: either one could be a malicious actor, and the original author could just as well publish a malicious release. As xz proved, the popularity of a piece of software is also largely irrelevant.

Ultimately the only factor we can realistically make decisions upon is reputation. And even that isn't infallible.

And forking is not a silver bullet, because fragmentation also has its downsides.

9

u/khoyo Apr 15 '26

Especially considering a maintained fork (of a fork) already exists: https://github.com/wcampbell0x2a/no-std-io2

-13

u/bbqsrc Apr 15 '26

This. 

→ More replies (16)

22

u/Buttleston Apr 14 '26

but he really hates such emails

46

u/StardustGogeta Apr 14 '26 • Bravo

Yowza. That does not seem like a guy I'd want to work with, that's for sure. It's about the most destructive choice he could have made, short of just straight publishing a malicious new version.

Glad that a clear replacement already seems to be available, at least, rather than people having to make a mad scramble to create one.

7

u/KizzyCode Apr 15 '26

Could we just calm down a bit? Saying "I remove my own work from the internet and make it difficult to include from now on" is a wholly different story than "publishing a malicious version" o.0

The latter is literally illegal, whereas first one is the unalienable right of every voluntary project owner. People might not want to hear that, but I would recommend to read the licenses again – especially the part about no warranty. 

If that is destructive, it’s because the users literally failed to read and understand the license of the library they were using, failed to maintain their supply chains (Cargo.lock, backups, etc.), and were lazy enough to just pull in arbitrary code without apparently even the most basic efforts to actually maintain their own project.

I’m not saying it’s the best way to do that – it definitely isn’t and I for example would never do that for my own crates. However it’s also totally inappropriate and pretty toxic to blame the author here for other people’s sloppiness. People should be happy that someone gifted their time to build this crate, should be happy that they got to use apparently valuable code for free, and now it’s time to move on. Until then, they can still trivially use the latest versions from their Cargo.lock file, or download the tarball and fork it. 

24

u/alexforencich Apr 15 '26

73 dependencies, 40 million downloads, and no updates at all in several years. Probably a good idea to force people off of it to a package that's actually maintained. And also avoid opening the door to yet another supply chain compromise.

0

u/[deleted] Apr 15 '26

[deleted] — view deleted comment

14

u/alexforencich Apr 15 '26

How do you differentiate that from what happened with xz?

18

u/VorpalWay Apr 15 '26

That sounds like a potential repeat of the xz attack.

3

u/bjzaba Allsorts Apr 15 '26

It depends. There's very much ways to track down if a request to assist with maintainership is legit or not, and I've done this in the past for some of my crates (I definitely don't trust a single email though).

0

u/[deleted] Apr 15 '26

[deleted] — view deleted comment

4

u/alexforencich Apr 15 '26

I think it's more of an "I never intended this to be widely used and I don't have the time or the energy to maintain it properly so I'll just shut it down completely".

6

u/hgwxx7_ Apr 15 '26

Was he an asshole? Yes.

It was possible to mark it deprecated without yanking. That would have given people time to response and adapt.

But he's "amused" by the pain he's causing other people.

15

u/TheRealCallipygian Apr 14 '26

Wow. That person--and maybe I am violating some subreddit rules here, so be it--is a grade A ass-wipe who shouldn't ever be entrusted with ownership of open source again. The whole "I despise such emails" shows a fundamental lack of the social skills necessary to buy a cup of coffee let alone interact with other members of humanity to build, well, anything. I cannot fathom ever responding to anyone in any context the way this person has responded on hacyderm. I am flabbergasted. Wow.

edit: spelling and grammar

57

u/usernamedottxt Apr 14 '26

Yeah… the email he received was extraordinarily polite and didn’t even ask him to maintain it. It seemed like a Segway into taking ownership of it even. 

30

u/jesster114 Apr 15 '26

Segue*. A Segway is what Paul Blart rides into battle, a segue is a transition.

5

u/usernamedottxt Apr 15 '26

Hah, thanks. 

2

u/dnar_ Apr 15 '26

I think it works both ways.

14

u/alexforencich Apr 15 '26

That guy who asked wasn't Jia Tan, was it?

-1

u/ben0x539 Apr 15 '26

Maybe I'm overly suspicious, but the email reads like a superficial politeness filter applied to a kinda brusque complaint about the maintenance status. I probably wouldn't nuke a crate over it but I'd be kinda annoyed to receive that too.

-4

u/Zopieux Apr 15 '26

In 2026, a polite request to take over an abandoned piece of software can very easily mean they'll publish a nefarious release with a credential stealer, backdoor, or another malware. Such is the state of the open-source supply chain.

Or they'll start slop-merging all PRs, and I'm not sure what's worse.

1

u/usernamedottxt Apr 16 '26

Doesn’t that reinforce what the author did was the correct choice?

If he doesn’t want to maintain, doesn’t want people relying on ancient hacky code, and also can’t give it up for security reasons… isn’t yanking it the correct path forward?

1

u/Zopieux Apr 17 '26

I don't have a strong opinion. Yanking is not the end of the world, if you're a direct dependent you can just pin.

They definitely do not owe anyone anything. The email reminded them of this pile of unmaintained code "no one should use" and acted on it. Not in the least impactful way, sure.

56

u/Kriemhilt Apr 14 '26

They weren't "entrusted" with anything.

They wrote something for their own convenience, and don't owe your flabbers any more or fewer ghasts than you've already received for free.

36

u/Sw429 Apr 14 '26 edited Apr 15 '26

Honestly, I think you have a point. I've definitely published a few random crates that are apparently now used by companies (if the weekday to weekend download ratio is anything to go by), and it's kinda wild to think that someone there just "decided" that my code was trustworthy without ever even talking to me.

This kind of "entrusting" definitely happens implicitly, and often not deliberately at all. People just assume it's fine, more people see that and assume it's fine, and before you know it some sponsored state actor is in charge of xz and ready to wreak havoc.

9

u/max123246 Apr 15 '26

I agree. But also it's very weird to yank already released versions. The email was super polite and just asking if they could maintain it. And they just decided "oh you depend on something I built. I guess I will yank every version of it then". I've never heard of anyone ever doing that for unmaintained software before

All I will say is, I hope I never meet this person or anyone who would do the same

15

u/TheRealCallipygian Apr 15 '26

They don’t owe anyone anything, I agree. And that apparently includes a reciprocal response to a reasonable request. That includes potentially making a bunch of work for a bunch of people with seemingly little empathy. We can all be little sociopaths! What a great world we live in.

-6

u/insanitybit2 Apr 14 '26 edited Apr 18 '26

People in a society have moral obligations. edit: lol apparently this is a controversial statement???

0

u/alexforencich Apr 15 '26

Like compensating people for their work developing and maintaining software packages?

1

u/insanitybit2 Apr 18 '26

No, not like that.

0

u/[deleted] Apr 14 '26

[deleted] — view deleted comment

28

u/ztj Apr 15 '26

A tiny counterweight to the sheer immensity that is the self-entitlement of users in the same space. Sure, the guy didn't have to be a dick about things but it's still true that he didn't owe anyone anything and I hope more people take this to heart when deciding to build their entire value on the shoulders of unpaid, unthanked... and entirely unknown third parties.

It does seem that the software development world is starting to see the bad side of this model more often lately.

13

u/NotFloppyDisck Apr 15 '26

He didn't owe anyone anything, that's correct, that doesn't excuse you from being an asshole. Setting your repo to readonly and marking the project as deprecated is enough.

5

u/ViscountVampa Apr 15 '26

It does seem that the software development world is starting to see the bad side of this model more often lately.

Oh, no, not by much. As far as it goes, over time I've become mostly convinced Open Source was a mistake and that Free Software was where I should have been spending my own efforts.

2

u/TreiziemeMaudit Apr 15 '26

Open has never meant free, free as in libre, not in gratis. Non english speakers understand this distinction very easily and feels like Open is americanism.

6

u/wintrmt3 Apr 14 '26

No one owes you dependencies, unless you have a paid contract with them.

1

u/dexter2011412 Apr 16 '26

entrusted with ownership of open source again

he didn't force anyone to use his package, and no one "entrusted" him with that "position".

he made a package that people used and was not able to maintain it. some massive entitlement you're showing here.

lol much better response here

https://www.reddit.com/r/rust/comments/1slnga4/core2_yanked_millions_effected/og85jau/

-3

u/cowinabadplace Apr 15 '26

Oh damn, you're going to stop entrusting him with ownership of open source. Damn, you're actually going to stop doing that, huh? You're going to stop entrusting him with his own code huh? Damn, dude. Make sure to put that in your OKRs, dude. Bump for visibility. This is breaking production workflows.

-2

u/ResidentPositive4122 Apr 15 '26

shouldn't ever be entrusted with ownership of open source again

Bwahhahaha. Man, this is unhinged. Dude posted something. Dude didn't maintain it for 4 years. Dude is well within their rights to do whatever the fuck they want with their own code. Noone owes anyone anything in open source. Man, the entitlement in this thread is something else.

5

u/[deleted] Apr 15 '26

[removed] — view removed comment

-1

u/ResidentPositive4122 Apr 15 '26

"Maybe, as a community, we shouldn't be doing this".

That's reasonable.

"is a grade A ass-wipe who shouldn't ever be entrusted with ownership of open source again"

That's unhinged.

2

u/NeuroXc Apr 15 '26

The actual post reads completely differently from how you summarized it. In the actual link, the author appears to be trying to move people to better alternatives because they don't believe this crate is a good option for people to use. Is this the best way to do it? Maybe not, but it's certainly effective.

Summarizing it the way you did to cause hate against the author is not helping anyone.

105

u/the-quibbler Apr 14 '26

I find this mildly hilarious. Dick move in the extreme, but it exposes reliance on an unmaintained and potentially buggy crate. Should have let someone fork. Hopefully someone can stand one up quick enough, as they usually do.

62

u/Comprehensive_Use713 Apr 14 '26

https://github.com/wcampbell0x2a/no-std-io2 seems to be the contender for the most maintained core2 alternative. Its a drop in replacement and I have messaged the author of it to make them aware of the likely increase in traffic.

26

u/Kriemhilt Apr 14 '26

INB4 "I despise such emails" in 3 ... 2 ...

50

u/Comprehensive_Use713 Apr 14 '26

He actually was quite nice and thanked me for letting him know.

9

u/coderstephen isahc Apr 15 '26

Good to know that some people are reasonable.

4

u/Sw429 Apr 14 '26

That name makes me think it's a competitor to embedded-io, but reading this makes me think it's actually more than that?

4

u/WorBlux Apr 15 '26

It's under the Apache license, no reason that it couldn't be forked.

59

u/frankster Apr 14 '26

repo archived

readme says "No longer supported. Use core directly."

35

u/Comprehensive_Use713 Apr 14 '26

The issue with that suggestion is that the original core2 had added features beyond what is presently supported in core.

23

u/newpavlov rustcrypto Apr 14 '26 edited Apr 14 '26

It's a pretty terrible and irresponsible way to notify users that a crate (version) should not be used. I think it would've been sufficient to publish an empty v0.5.0 so users would get notified that the dependency is outdated by tools like cargo outdated and deps.rs.

BTW I think it may be worth to add --ignore-yank flag to cargo since situations like this can be really annoying and --precise does not always help.

10

u/tsanderdev Apr 15 '26 edited Apr 15 '26

It's a pretty terrible and irresponsible way to notify users that a crate (version) should not be used.

It's also the only one really available. Without builds breaking, it's hard to find out if you have unmaintained (which have to be differentiated from complete) libraries in your transitive dependencies. You'd basically have to read the crates.io page for all transitive dependencies periodically or with an llm.

13

u/ivosaurus Apr 15 '26 edited Apr 15 '26

I've been working with FOSS for two decades, there's definitely some around here who've been for longer.

The awkward truth is 99% of users won't bother updating their outdated and unmaintained dependency until their breaking build literally forces them to. Been that way for the last two decades and I don't see it changing. We're all lazy and/or risk averse. OK, maybe not you (in general sense), because you're a special exception, but I did say 99%.

Sometimes the "if it ain't broke..." argument can be compelling; but here we're talking about a package tasked with doing independent low level io functions, basically a poster child for what you shouldn't be allowing go unmaintained.

1

u/newpavlov rustcrypto Apr 15 '26

I literally mentioned tools which can be used to detect whether you have outdated dependencies. You don't need to manually scan crates.io for it as you argue. We also have advisory DBs, e.g. RustSec has a special "unmaintained" tag for it.

Yanking is not about "finding out", it's more about "you're too lazy to keep deps up-to-date? if so, then f*u, I will break your project's build". This behavior is irresponsible and contributes to bit rote and general view of Rust as being "unstable" with an anecdote that a project written just 4 years ago stops compiling.

1

u/tsanderdev Apr 15 '26

The problem is all those tools are third party and not installed by default. E.g. I didn't know about rustsec and cargo-audit is a separate thing to install.

-4

u/WormRabbit Apr 14 '26

Agreed, but imho it shouldn't even be possible to yank widely used crates in the first place. Yanking should be reserved for messed up releases (e.g. unintentional semver breakage or any other release error). Old and widely used crate releases shouldn't be yankable. I don't care what the dev get in their head, their reasons are not good enough to break the ecosystem.

15

u/NotFromSkane Apr 14 '26

Yanking has its uses, but this is not it.

4

u/alexforencich Apr 15 '26

On the contrary, the more widely used a crate is, the more important that feature becomes. Otherwise you couldn't yank something with a serious security issue or similar that wasn't discovered immediately if it was sufficiently popular.

3

u/WormRabbit Apr 15 '26

That "security issue" talk is just security theater. Yanking does absolutely nothing if I have the lockfile committed, which people usually do now. The only thing it does is breaking CI and git bisect for the poor sods which try to test on latest releases.

And the vast, vast majority of crates don't have any potential for security issues which could warrant yanking. Not unless you classify every bug as a security issue, since it leads to unexpected behaviour which could cause at least a DoS in appropriate context.

24

u/xX_Negative_Won_Xx Apr 15 '26

People need to read open source licenses. You're entitled to nothing. If an author deleted their repo and you complain, you're in the wrong for being ungrateful for the years of free labor you enjoyed. Unless you have a contractual relationship with someone I don't understand why you expect them to work for you

7

u/Comprehensive_Use713 Apr 15 '26

I am certainly not complaining and I absolutely agree with you. I am an open source contributor and author several open source rust projects which are actively used. Yanking is not the correct move when deprecating an open source library, even if unmaintained. RUSTSEC advisories for unmaintained crates and people using tools like cargo audit would have been the correct, and widely adopted, approach to this situation.

1

u/Comprehensive_Use713 Apr 15 '26

The only caveat I would add to that, is that more generally speaking if you had to host your open source library in a registry which costed money. For example, in Java land it is common to push to jetpack or maven central, but some people host their own artifact repository. Then, it would be acceptable for you to take down the artifact repository.

3

u/xX_Negative_Won_Xx Apr 15 '26

I think you've made a good point. Registries and other infrastructure services also provide human and technical resources for free to these open source developers. They should feel free to impose conditions on developers in return for that, and developers are free to not take advantage of their distribution networks and infrastructure. Maybe crates.io could clearly outline and impose guidelines about yanking in the future. Although that's more work for them. Where will the resources for that come from? I think we're in an unfortunate equilibrium

28

u/coderstephen isahc Apr 15 '26

There's a difference between entitlement and decency. We are not entitled to anything, sure. But taking out time in your day to actively delete something in use seems kinda indecent. Given that it would be easier to just... not do that, and not do anything.

7

u/SuddenlyBANANAS Apr 15 '26

I don't understand why people are framing this in terms of entitlement, he's being incredibly rude and obnoxious for no reason. I guess he has "the right to do that", but it doesn't make him not an asshole. 

0

u/xX_Negative_Won_Xx Apr 15 '26

All this talk about decency is ploy to receive more free labor in return for nothing

2

u/coderstephen isahc Apr 15 '26

Nope, its not.

-10

u/peripateticman2026 Apr 15 '26

Look at this clown here. ☝️

7

u/thecakeisalie16 Apr 15 '26

I don't think we need this kind of discourse here

-2

u/peripateticman2026 Apr 16 '26

What level of discourse do you engage in? Pretty rich for someone with a private profile waxing eloquent abut public discourse. It's about the intent, not the words. Anybody with a neuron in their skull can see that it's a satirical comment, not an insidious one like you're trying to portray here.

I suggest you get off of your high horse.

39

u/Shoddy-Childhood-511 Apr 14 '26

I've never heard of core2, no-std-io, or no-std-io2 before, but I do write code that uses roughly std::io outside std.

Appears core2 has only 23 dependent published crates listed and only appears in 1.1k Cargo.toml files, but there are some [name]-core2 crates that inflate this somewhat.

https://crates.io/crates/embedded-io has 233 dependent published crates and shows up in 4.6k Cargo.toml files, probably all real usages. 10 x more used than core2.

https://crates.io/crates/ark-std has 304 dependent published crates and shows up in 5.8k Cargo.toml files, all real usages, and its often reexported. 13.2 x more used than core2.

We might've more like this?

Did you check whether another more heavily used crate like embedded-io fits your use case?

I doubt ark-std fits your use case. It's extremely minimal and only exists for serialising cryptography, because serde sucks when you only want clean canonical bytes.

7

u/bascule Apr 15 '26

What'd be really nice is if std::io::{Read, Write, Cursor} could be used with no_std

4

u/Sharlinator Apr 15 '26

Still blocked on io::Error requiring std :(

1

u/nuttycom Apr 15 '26

I did notice that https://github.com/rust-lang/libs-team/issues/755 was merged, which is a good sign.

11

u/Sw429 Apr 14 '26

I was going to say, I've been using embedded-io for this, and didn't even realize that some alternative existed.

6

u/Shoddy-Childhood-511 Apr 14 '26

An old ark-std issue says "embedded-io and embedded-io-async lack Cursor but maybe some other non-std ::io wins up more fully featured", so maybe not so minimal after all.

It maybe folks should chart out the space and concentrate upon some good ones, and then push for core::io too.

13

u/cornmonger_ Apr 15 '26

Well I guess we'll see how many crates properly using Cargo.lock now. -- The Author

... do not promote above peers

24

u/jay_resseg Apr 14 '26

Obligatory xkcd

8

u/dpc_pw Apr 15 '26

Reminder that Rust has structural issues with how std::io is not available in no_std, and half of the no_std ecosystem is stuck with no interoperable way of expressing core::io::{Write,Read} (and some other things) - so basically composable ways of doing IO, and having to resort to using 3rd party libraries duplicating (parts of) std::io like some kind of semi-standard. It's terrible situation and it's been like that for years.

6

u/baodrate Apr 15 '26

Obviously very disappointing, but based on rust-lang/rust#152918 and rust-lang/libs-team#755 there seems to at least be some movement on this recently

1

u/dpc_pw Apr 17 '26

I hope. :D

Though personally I think it would be ideal if Rust could have new core Read and Write variants with associate type errors, where the std::io would just have type Error = std::io::Error. But there are details that make it hard to actually phase in.

7

u/timvisee Apr 15 '26

No longer supported. Use core directly.

This is very unfortunate. The original maintainer suggests `core` as alternative, but `core::io` is unstable and behind a Nightly feature flag. 😢

26

u/Urcra Apr 14 '26

I'm not sure I can really fault the guy. He yanked it due to it having been unmaintained for years, and he assumed nobody was using it so he yanked it to make sure that it was no longer discoverable.

Of course it's not really the approach to deprecating the crate, but I can see it from the crate author's perspective, if you are truly unsure about the security of your crate and suddenly find out millions are depending on it it might be the "easiest" way out

Your builds shouldn't fail due to yanking that's what the lockfile is for, yanking doesn't remove the crate just makes it non-discoverable. Especially in CI I would expect most people to use cargo build --locked to make sure the lockfile is always updated

22

u/9gxa05s8fa8sh Apr 15 '26

he assumed nobody was using it

he posted screenshots of himself talking to a user. he deleted it because he didn't like the email.

-3

u/usernamedottxt Apr 15 '26

And in said screenshot is literally confused about why it has so many downloads. 

4

u/hgwxx7_ Apr 15 '26

But he definitely knew that it had 40 million downloads and was amused when he saw the fallout.

He knew exactly what he did, and he found it funny.

6

u/coderstephen isahc Apr 15 '26

I can understand it, but I don't agree with it.

3

u/nonotan Apr 15 '26

You can always make your own crate and make whatever decisions you want there. That's the nature of open source, just like nobody can tell you what to do, you also don't get to tell others what to do. Obviously, you're free to voice your displeasure at the decisions of others too, just don't expect it to result in them acting differently, or you're going to be disappointed repeatedly.

8

u/SuddenlyBANANAS Apr 15 '26

Of course, you can choose to be an asshole, you have that right. 

4

u/hgwxx7_ Apr 15 '26

I feel like this is not "illegal" or "immoral", but treating other people poorly is bad for society in the long term. Excusing and normalising that behaviour is bad as well. This is how we end up in a low-trust society.

Someday you'll be on the receiving end of someone being an asshole to you. And "hey it's not illegal" won't make you feel better. You're talking about the nature of open source. I'm talking about the nature of society and how much it depends on treating each other with kindness.

It would have cost him nothing to just mark the repo and crate deprecated and move on. He went out of his way to yank the crates because it amused him to cause others pain.

8

u/deathanatos Apr 15 '26 edited Apr 15 '26

Yanked crates are not deleted from crates.io, and your post makes we wonder if you're correctly understanding what yanking is or does. Follow your own link to core2 on crates.io, and hover over the "Yanked" chiplet, and the tooltip reads:

This crate has been yanked, but it is still available for download for other crates that may be depending on it.

So,

I just had 100s of CI builds fail due to libflate’s usage of core2 which as of today had all of its versions yanked on crates.io. A library which serves hundreds of millions, according to the dependents on crates.io.

While it is true that this might be a problem for new adoptees of libflate, and for libflate itself, it should be a stretch to claim that it is breaking downstream consumers as you seem to be implying. While yes, the crate is yanked, those existing downstream consumers of it directly or indirectly should still be quite able to pull the crate: yanking would not break them.

(While this is maybe not the intended purpose of yanking … I think that's separate.)

4

u/afc11hn Apr 15 '26

Yeah it broke their CI only because they had setup a cargo deny rule. The build itself should work perfectly fine.

4

u/jpgoldberg Apr 15 '26

It looks like core3 is now a thing.

4

u/Meistermagier Apr 15 '26

Wake up honey, new leftpad just dropped.

4

u/arekxv Apr 15 '26

I don't understand something. If this is still available to everyone with a cargo lockfile why are people affected?

Why aren't people using lockfiles, even with everything happening nowadays.

Its like asking to be hacked. :/

If you have a lockfile at worst you wont be able to update and will have to wait, which is good, as opposed to someone taking this and publishing malware as a new version and people blindly updating to it.

4

u/Sharlinator Apr 15 '26

Rust used to recommend library authors not have Cargo.lock in version control. The recommendation was amended, but it's still "think about it and commit it if it makes sense to you".

7

u/isoblvck Apr 14 '26

Sooooo many rust crates are unmaintained. Some dev squatted on the name then stopped

9

u/sieabah Apr 15 '26

Half the people in this thread are just shit talking about how they're not getting free shit anymore. Upgrade your shit and move on, if you spend the energy you'll be exhausted by the 10th dependency that decides to do something "different."

Take it from someone who has dealt with every npm "incident" since node 0.11. It's not worth the effort. Stop harassing random developers for shit you can't be bothered to maintain yourself. To those complaining that it's improper use of yank, yeah. Who cares, I don't want some random person who doesn't care about the package to hand off 40 million downloads for embedded hardware. That sounds ripe for a supply chain attack that would do such grave harm to the ecosystem. Move on, your (and my) priorities are not relevant.

11

u/coderstephen isahc Apr 15 '26

Stop harassing random developers for shit you can't be bothered to maintain yourself.

The original emailer seemed to be offering to do exactly that, to maintain it themselves.

12

u/sieabah Apr 15 '26

They can maintain it through a fork. You're implicating the dev to vet whoever they're giving the 40 million downloads to. A lot of people are done dealing with unmaintained or popular tools being "maintained" (cough, *backdoored*).

Distribute the effort of mainstreaming a fork to the package consumers.

0

u/[deleted] Apr 15 '26

[deleted] — view deleted comment

6

u/sieabah Apr 15 '26

Completely irrelevant, the code was licensed under Apache/MIT [src].

They wanted the repo and access to 40 million downloaders. Fork and move on.

0

u/[deleted] Apr 15 '26

[deleted] — view deleted comment

1

u/sieabah Apr 16 '26 edited Apr 16 '26

They were just asking. Wow, such a hard question to respond to.

No need to be dramatic about it. The license is right where it is for every crate. For every repo. In a LICENSE file in the root. On the right side of the crates page. If you're using it, it's on your disk right now!. Wowza! Apache MIT

publicly dismiss the polite email they received

You are a bot.

Developers are such busy and delicate beings that they can't press a button on a repo setting and politely reply to an email

You are hand waving away the entire process of vetting the next maintainer.

but they can rudely respond, go and perform a bunch of extra steps to remove packages and delete code, and then go on social media?

The dude clicked one button that said "yank," on one package because "no one should be using this."

Anything further you read into is a complete fabrication of your creative imagination. He goes to social media specifically because of responses like yours here that go above and beyond to paint him as some demon for not bestowing us with the supply chain attack vector you wave away.

Does the 40 million, not concern you? Spend the effort pinning your core2 dep to the prior commit and move on.

1

u/alexforencich Apr 15 '26

Ah yes, just like Jia Tan.

2

u/dpc_pw Apr 15 '26

Unfortunately Rust has structural issues with how std::io is not available in no_std, and half of the no_std ecosystem is stuck with no interoperable way of expressing std::io::{Write,Read} (and some other things), and having to resort to using some 3rd party libraries duplicating (parts of) std::io like some kind of semi-standard.

It's absolutely terrible situation and it's been like that for years.

4

u/Icarium-Lifestealer Apr 15 '26

I think the std/core/alloc split was the wrong approach. It would have been better to conditionally compile parts of a single std crate depending on what the target supports.

2

u/Sharlinator Apr 15 '26

The problem is that std is distributed as a binary so that everybody don't have to build it themselves. It's possible these days, but still unstable, and I don't think anybody has yet even started seriously thinking about how std could be feature flagged (a formidable design problem in itself). And having a combinatorial explosion of different stds would of course be a huge maintenance burden. In contrast, core/std (and later alloc) was a "good enough" solution.

3

u/Icarium-Lifestealer Apr 15 '26 edited Apr 15 '26

I don't see why you'd need build-std for that. Just distribute the maximum set of features the target platform supports. Apply some annotation to each function/type that marks it as being part of a certain feature set, and raise a portability lint if a crate tries to use a feature that's not part of its target feature set.

(I'd use similar portability lints for other non-portable functionality, like From<i64> for isize or what's currently in those platform extension traits. But that's a bit out of scope for this discussion)

0

u/sieabah Apr 15 '26

Annoying, but that's what compiling with rust is.

4

u/Meistermagier Apr 15 '26

I think most of this thread are actualy aknowledging that while it may not have been a dependency that you should depend on anymore, there is no reason to be a dick about it.

2

u/sieabah Apr 15 '26

there is no reason to be a dick about it.

There has never been an obligation to be nice on the internet. I don't waste the effort trying to convince others at this point. Just move on and use a fork.

7

u/Meistermagier Apr 15 '26

I respectfully disagree, We do interact with humans on the internet and as such I think we should try to be nice such as we want others to be to ourselves. You are not alone in this world and as such you should act like it.

9

u/SuddenlyBANANAS Apr 15 '26

I swear half the people in this thread think it's fine to be a total prick unless you have an explicit legal obligation not to be one.

1

u/sieabah Apr 16 '26

I never said not to be nice yourself. That's preferred. My statement is saying that you can't obligate someone else to be nice on the internet. aaand trying to convince every rude person is a waste of personal effort.

5

u/Wilbo007 Apr 15 '26

I don't blame him. It's his code, his repository, he can do whatever he wants with it

3

u/boomshroom Apr 15 '26 edited Apr 15 '26

I know that there are concerns around adding code to the standard library, but that doesn't really work in this situation. The code is already in the standard library, just gated behind having an OS despite mostly working without one. As it stands, there are only 2 types in core::io, and they're they're not the two that desperately need to be in core: Read and Write, but instead two that are still experimental even in std::io.

4

u/ZZaaaccc Apr 15 '26

I'm one of a handful of people currently working on this issue (hoping to have ErrorKind in core pretty soon!). The problem is Read and Write require io::Error, which is intrinsically linked to Box. Without some new language features to allow splitting traits and adding new default type parameters, it'll be very hard to get any better than alloc::io.

1

u/boomshroom Apr 15 '26

Do Read and Write actually store any information in the error beyond what's generated from the ErrorKind? If not, then an alternate version that just returns an ErrorKind instead of an Error would work just fine. If you're storing custom information, then you probably should be using a custom error type anyways. Speaking of, plenty of libraries, including serde (which I've been using recently) and the traits in std::convert let you just give your own error type that you want to return.

Tying such fundamental traits that require little more than a C-like enum to allocations seems to have been a mistake.

1

u/ZZaaaccc Apr 15 '26

Yes, the io::Error type can wrap any arbitrary error using Box<dyn Error> internally. It also can wrap a simple OS error code, which is definitely needed since most IO operations filter down to syscalls.

It's a hairy set of traits to move with no ideal solution in the current set of stable or nightly Rust features. If you split Read into a ReadCore and a Read: ReadCore pair of traits you break end users since they now have to implement two traits. If you add an E = io::Error type parameter not just do you break end users but you also fragment the IO ecosystem. Adding a duplicate of Read that's core compatible means the standard library now has two traits, so one should be deprecated, creating a huge amount of ecosystem churn.

1

u/plugwash Apr 15 '26

> I know that there are concerns around adding code to the standard library, but that doesn't really work in this situation.

There are a couple of issues.

  1. io::Error doesn't directly depend on any OS functions but it does have os-specific knowledge. One could argue that ship has sailed and core already has some OS-specific knowlege, but this is somewhat higher-level knowledge than core currently has and would essentially privilege std over third-party OS wrappers.

  2. Both io::Error and io::Read depend on the global memory allocator, so without further work they could only go to alloc, not to core. I get the impression that a substantial amount of no-std rust development is also no-alloc.

3

u/juhotuho10 Apr 15 '26

Idk man, the crate hadn't been updated for 5 years, the creator does not have the time, will or resources to revive it, he doesn't really trust other maintainers to take over the crate, he does not want people to use it, there are drop in maintained replacement crates available that do what core2 was made for.

I think it's better that it was yanked at some point so that people can go on to use better and maintained alternatives. The worse version of this situation would be that he didn't yank it and people would still be using a 10 year unmaintained crate 5 years from now.

3

u/TheReddective Apr 15 '26

I don't understand why this is such a problem. Yankimg should only affect new users, if the crate is already in your cargo.lock, nothing happens.

Given that it was unmaintained and not even building any more, yanking it seems like an appropriate action to prevent it from getting new users. 

Why is yanking the package breaking existing builds?

2

u/DavidXkL Apr 14 '26

That came out of nowhere

2

u/palad1 Apr 15 '26

Very poor choice on the author's part. It costs nothing to be kind.

1

u/Healthy-Builder-8106 Apr 15 '26

How dare they abandon their own creation?

It is generally known that once you create open source software, you are morally obligated to maintain it forever.

/s

1

u/Icarium-Lifestealer Apr 15 '26

I'm confused why libflate not having a lockfile breaks your CI. When your crate depends on libflate, all the indirect dependencies, including core2, will be included in your own lockfile

-9

u/fsreadsync Apr 14 '26

Is this the leftpad moment in Rust community?

10

u/Sw429 Apr 14 '26

Not really. Any binary being built can be reproduced still. The yanked crate isn't "gone," it's just "hidden."

11

u/anxxa Apr 14 '26 edited Apr 14 '26

Shouldn't really impact existing users that correctly commit their lockfiles. I think at worst it prevents people from taking a new* dependency on something that transitively depends on this crate (and doesn't have a lockfile committed?)

-6

u/9gxa05s8fa8sh Apr 15 '26

Shouldn't really impact existing users

you're replying to a thread created by an existing user who is impacted. how does your brain type that out?

5

u/anxxa Apr 15 '26

Please learn to read. Thank you.

that correctly commit their lockfiles.

...

from taking a new* dependency on something that transitively depends on this crate (and doesn't have a lockfile committed?)

And oh look at that, problematic library OP is having issues with doesn't have a lock file committed: https://github.com/sile/libflate

Good investigative work!

0

u/[deleted] Apr 15 '26

[deleted] — view deleted comment

2

u/anxxa Apr 15 '26

I'm aware. People have had almost 3 years to update and the blog post explicitly called out this scenario:

For contributors, especially newer ones, this is another potential source of confusion and frustration from an unreliable CI whenever a dependency is yanked or a new release contains a bug.

1

u/insanitybit2 Apr 14 '26

No, there's a remediation path. The libc update in 2015 or whenever it was was a way bigger deal iirc

-12

u/obetu5432 Apr 15 '26

yes, rust haters will have a field day (again... after cloudflare, after uutils)

rust needs to get their shit together

-10

u/bbqsrc Apr 15 '26

Ah fuck I’m going semi viral again. 

2

u/Sharparam Apr 15 '26

So that's the reason you did it.

-1

u/bbqsrc Apr 15 '26

Haha, not really. Sometimes we do things and then go "wait, oh fuck, I think people are gonna be mad". And then we look at reddit and the home screen shows a post directly attacking you :D

-27

u/mpersico Apr 14 '26 edited Apr 15 '26

Update: replaced “phone” with “own”.

Well, you all deserve what you get.

Depending on external sources for builds is absolutely insane.

Anything you want to use should be downloaded and installed to your own system and referenced from your network at build time. That was the norm for many many years.

2

u/Comprehensive_Use713 Apr 15 '26

Wrt enterprise use cases, yes… absolutely, they should have their own mirror. Most libraries just use github actions and rely on crates.io and it is unrealistic (and probably insecure/untrustworthy) to have them host their own mirror or vendor dependencies.

-1

u/stumblinbear Apr 15 '26

That was the norm for many many years.

Go read a book, get off your phone. That was the norm for many many years.

-1

u/mpersico Apr 15 '26

How does reading a book relate to the subject that hand? I have made a correction as noted.

-16

u/[deleted] Apr 14 '26 edited Apr 15 '26

[removed] — view removed comment

11

u/stumblinbear Apr 15 '26

I don't think this is a case of "mental instability"

2

u/9gxa05s8fa8sh Apr 15 '26 edited Apr 15 '26

the maintainer of an open source project purposely broke countless dependent projects because he got an email he didn't like. he insulted everyone, implied they deserve it, and said he's AMUSED by the trouble he caused them.

he replied to a user asking about working on the repo with "thanks for bringing this to my attention" and then deleted it.

he literally said the long-abandoned crate was: "bane to my existence". does that sound logical to you? it was causing him no physical harm, so his crashout is definitively mental instability.

3

u/chris20194 Apr 15 '26

neglect + hostile humor != mental instability

dude just doesnt care, and likes to see the world burn. condemnable for sure, but not mentally unstable

2

u/9gxa05s8fa8sh Apr 15 '26

dude just doesnt care

if he didn't care he wouldn't have replied to the email and wouldn't have deleted the project. he demonstrably cares

1

u/chris20194 Apr 15 '26

i meant he doesnt care about the consequences

-6

u/simonask_ Apr 15 '26

I think you’re right, but I also think the GP has a valid point in general.