For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)
As the victim of the one from last year, it wasn't particularly fun to read.
The implication that I don't know what I'm looking at, or that I don't know what security is (despite having a clean track record for about 15 years now) was a bit aggravating.
In fact, even months later, the lasting effects have been panicking over anything that is remotely suspicious. The most recent example was just a few days ago. Had just gotten on the plane to go on vacation when someone Liked the original "I've been pwned" post on Bluesky. I misread the notification as being a new message to me saying "You've been pwned" and started to panick. I'd have had no way to address it and it would have ruined the small chance per year I get to have a break.
The attack last year wasn't me misunderstanding security. It was the sum of many, many small things (my history with and perception of npm especially w.r.t. their security posture and poor outreach over the years, being stressed out overall, and being in a rush at that particular moment, and a few other personal things) coming together in a perfect storm that resulted in the attack.
> The implication that I don't know what I'm looking at, or that I don't know what security is (despite having a clean track record for about 15 years now) was a bit aggravating.
I'm a security geek, a clean track record means much less to me than anyone would expect. The comment from the article mentioning that there was no evidence of exploitation explains why. I would never have noticed that implication, because I don't think it exists. (And it's completely unreasonable if it does), so that's your own deal... it's not a good conclusion to take from the article.
The only thing that matters is how much any given owner cares. Are they willing to go the extra mile to make sure things get done correctly. That's the best signal about if you can trust a project. Seems like you give a shit, so I wouldn't be too hard on yourself. The people that matter can tell, (everyone who can't tell is already willing to lie so they can be safely ignored!)
> In fact, even months later, the lasting effects have been panicking over anything that is remotely suspicious. The most recent example was just a few days ago. Had just gotten on the plane to go on vacation when someone Liked the original "I've been pwned" post on Bluesky. I misread the notification as being a new message to me saying "You've been pwned" and started to panick.
You haven't dealt with it yet, if you want to get your attention back so you can spend it on more important things than worrying about something from the past, you gotta talk to somebody. A therapist would help the fastest, but friends and family are often just as good.
> I'd have had no way to address it and it would have ruined the small chance per year I get to have a break.
Seriously, having been there myself it's not worth it... you're just allowing them to DoS your brain by allowing them to live rent free in your head. The only thing that matters is how seriously you take the remediation. Attention to detail, and the willingness to go the extra mile for security defects to tie up all loose ends is what matters. It's not your job to fix everybody's issue yourself, even if they don't or can't. You still have to enjoy life, or you burn out, and some idiot that doesn't care will take your place. Then they really win.
You're not responsible for the security or stability of anybody using nightly packages. (Only maintainer signed and tagged releases)
> The attack last year wasn't me misunderstanding security. It was the sum of many, many small things
so, a misunderstanding of how the little things actually impact security?
> (my history with and perception of npm especially w.r.t. their security posture and poor outreach over the years, being stressed out overall, and being in a rush at that particular moment, and a few other personal things) coming together in a perfect storm that resulted in the attack.
Those other personal things are the kinda thin that being able to enjoy a vacation make much easier. You can't help anybody if you don't put on your own mask first... Well... You definitely can, you're obviously trying to do now, but it's needless harder.
Npm, and the JavaScript ecosystem is a fucking joke. It's a mistake to blame yourself (or any maintainer) for how difficult it is to meet the bar for both security and accessibility. Worrying about the difficulty in consistentenly demonstrating the perfection required for security is a fool's errand, and your allowing the bad guys to get what they want by letting it live rent free in your head, it won't go away for as long as you worry about it more than you talk about it.
And I say all of that as the person who has multiple times, made the argument that it's perfectly fine to name an engineer and their decisions or incompetence as the root cause analysis in an official incident report. (Pilot Error is a thing): If I thought you were responsible, or had done anything wrong, I'd gladly blame you. Smart people don't care about mistakes, because they are always noise in the signal. I care about effort. People who give a shit are much more important and valuable.
Well, the one I linked to is real. BIP-42 made bitcoin's monetary policy fixed, by fixing a bug in the client which would have resulted in the initial subsidy code being reset every ~250 years or so. It's just the official writeup documenting it that is silly.
obviously it's referencing the left-pad incident[0], and to 'justify' text is another kind of text manipulation[1]; but with the more common definition, i guess it's a joke about justifying something? The Left? idk
No, the meaning is straightforward. It's a joke because the audience is assumed to write in a left-to-right script (such as English), such that text is already left-justified by default.
Searching for CVE-2024-YIKES also provides a gallery of AI slop blogs that AI-rewrite the content of this post while being absolutely stone cold serious about it.
Googling is no longer a reliable way to figure out if something is real or not (since, in this case, it just regurgitates the original article, including a couple slop blogs about it)
The dependency cycle is actually the functional mechanism of the code, because they subvert the dedup mechanism in the package manager using a random generation trick. Each recursive copy of the dependencies takes up a little bit more space, which ultimately gets converted to the spaces inserted into the original datum; the caller is expected to adjust the cache settings to signal the desired amount. That's also why if you're using left-justify to process strings, Yarn is recommended for best compatibility. /joke
Just because it's not important to pay attention to CVEs, why not waste the readers' time by creating "fictional" CVEs without a disclaimer in the first line? Just because it's not already difficult to scrape through the information and noise on this internet...
especially if it appears on the front page of hackernews
Have you not read CVEs as of late? As a precondition for getting their funding back, all the doge boys get to write the CVEs for their own orgs. Insane parentheticals about trans people is the norm now.
I saw a comment very similar to this on a blog post testing the Copy Fail exploit, where someone was complaining that without a tl;dr at the top, it took too much effort for them to find out whether the blog post documented a new exploit. In fact, reading less than a paragraph already showed that couldn't be the case; the table of contents is enough.
If a glance at the CVE number that isn't a number doesn't do it, a minute or less of skimming this article likewise reveals it to be satire on a blog that's actually pretty thoughtful when it comes to supply chain attacks.
Idk how else to characterize this except as a literacy problem. Learn to skim. It should be unacceptable to characterize a few minutes of reading as unbearable toil. If your time is really so precious that (although you can surf Hacker News) you can't spare 1-3 minutes to read, surely you have someone else to whom to delegate the responsibility of watching for supply chain attacks.
> Day 1, 14:47 UTC — Among the exfiltrated credentials: the maintainer of vulpine-lz4, a Rust library for “blazingly fast Firefox-themed LZ4 decompression.” The library’s logo is a cartoon fox with sunglasses. It has 12 stars on GitHub but is a transitive dependency of cargo itself.
I got a bit curious and here is an incomplete list of crates to compromise to be part of the cargo build and that already have a build.rs so it doesn't stand out to much:
flate2
tar
curl-sys
libgit2-sys
openssl-sys
libsqlite3-sys
blake3
libz-sys
zstd-sys
cc
As a nice bonus - if you get rights for xz2 you can compromise rustup.
-sys crates are just bindings and doing something else in them is highly suspect. The rest I recognize as being owned by a Rust maintainer like alexcrichton or rustlang itself.
With crates.io using GH as its IdP, I think there would be much farther reaching consequences to account pwning in that scenario. I agree, though, that the security model for crates.io is only as strong as the weakest link there, and would pray someone like Alex is using physical tokens or the like for his MFA and can't be conned by a well-crafted email.
sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
I had pondered the same thing about other package ecosystems in the past, in general. Now with the benefit of hindsight we can comfortably say that the absence of known (!) attacks doesn't really say anything about how relatively difficult an attack would be. Are -sys crates, or build script attacks, particularly potent? Who knows. When I did a cursory search, the only attempts I saw were at runtime rather than build time[1]. Which raises a good point; pwning a developer machine or CI box with a build script may be quite valuable, but if you might get that and prod with a runtime exploit, is the build time exploit that much more valuable? Guess it depends! (Of course, I personally think having at least optional build time sandboxing is even better than hoping it won't be valuable to attack.)
Of course, crates.io has surely had some malicious packages. (I'd assume it isn't all that unlikely there could be some undiscovered right now; it's definitely large enough for something like that to slip under the radar, even if it is relatively small compared to say, NPM.) But, I think it really hasn't had its XZ backdoor moment, its left-pad, where you really get to see how well it does or doesn't handle a serious challenge. Since I have actually not published on crates.io, I'm not really sure how the security posture is, but if it's more similar to other programming language repositories than it is to Linux repos, I dunno exactly why it would be hard to believe a high-level compromise is possible and could slip in (really, anywhere, be it a build script or otherwise.). Of course, "would not be difficult" is all relative. I'm sure many of these attacks are not really all that simple, but a lot of them aren't exactly groundbreaking either. It was well executed and took quite a lot of time, sure, but there wasn't all that much about the XZ backdoor that was novel. (Except maybe the slyness with which the payload was hidden in test files. That was pretty cool.)
ou can defend a claim that literally anything is a supply-chain risk from this logic. Don't use vim to edit your config files because you don't have any way to know that someone couldn't slip a "reflections on trusting trust" compiler attack into clang so that your MacOS binary distributed by homebrew detects when you're editing an npm.json and exfiltrates your ssh keys so that they can push rogue builds!
Yes. Your comment reads to me as a defense of the comment above the one you replied to:
>>> sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
>> Surely that's why we see evidence of all these build script attacks, since it's so easy?
> Now with the benefit of hindsight we can comfortably say that the absence of known (!) attacks doesn't really say anything about how relatively difficult an attack would be.
Given that you were responding to a critique of what seems to be fully conjecture with the argument that we don't know for sure that it's not feasible, it's not clear to me why that wouldn't be a sufficient defense of any claim of a potential vulnerability without regard for merit. You don't propose any alternative than ignoring the only hard evidence we have, so although you might not have intended it this way, it's not clear to me what discussion you could expect to happen with that standard of evidence other than throwing up our hands and saying everything is screwed.
We do in fact see them a lot. Typically they target Python or Node because those ecosystems are much more popular than Rust. But build.rs provides exactly the same opportunities to attackers for Rust.
No, we don't. We see build system attacks, such as injecting malicious scripts into their CI and getting malicious code into the artifact for use at runtime. You don't see someone doing a drive-by PR to a `setup.py`.
Not a drive-by PR, but once a package is compromised it often does spread to its reverse-dependencies via mechanisms like setup.py at build time. There was case like this with setup.py less than two months ago: https://www.stepsecurity.io/blog/forcememo-hundreds-of-githu...
Lots of npm supply chain attacks propagate at build time via post-install hooks, too.
It's easy to be cynical because, yes, both the problems and solutions seem dead obvious in hindsight. But for a long time (and maybe even still), a hacker creed was "move fast and break things."
It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic development.
I'm not just talking about Mythos/Glasswing surfacing vulnerabilities in pretty much everything it touches; I think the way we're developing software, pulling in dependencies, and potentially losing human thought modeling of complex systems is going to lead to a lot of hacked together software and infrastructure that humans won't fully understand.
I hope in a few years we don't look back at today and wonder how we could have been so naive -- how we failed to actually plan for the long-tail of AI development in a way that doesn't solve problems by attempting to just use AI to rebuild complex systems.
He certainly popularized it (maybe coined it), but I've seen a lot of organizations and developers repeat that mantra.
Even without the specific words, look to product teams debating tradeoffs of going to market vs. waiting for better security controls. They're pushing for faster product release every time, at pretty much every org.
Hackers were moving fast and breaking things first. Faster than any corporation in fact. We didn't notice because their computers weren't powering anything useful. How do you think projects like GNU happened?
I stand corrected! My memory is pretty vague on this, but I was pretty sure Joel had said something very close to this in one of his blog posts in the early 2000's, but it looks like Zuckerberg was the first one to use the phrase "move fast and break things":
We don't need hindsight for the problems of supply chain security to be obvious. Security people were writing and doing talks about this stuff over 10 years ago, just (like most things in security) things start getting addressed once the pressure of incidents gets high enough :)
I actually wonder if somebody used a fake identity to set up an account with a warehousing/shipment fulfillment company that stocks things and ships them, then set up the appropriate EDI pipeline to send shipping orders to it... What would be the results if a decently budgeted adversary made something attractive looking that shipped malicious USB flash drives to anyone that requested one.
I know we're not in the era when a windows pc will happily run any autorun.inf and .EXE file found on an inserted flash drive or DVD anymore. But even so. What if it didn't even have any malicious data payload but somebody was shipping USB-A interface capacitor based usb killers?
What if it did have data on it and came with a slick color brochure walking people through how to run the binary, or in a linux or developer specific audience, how to 'sudo' the ELF binary that lives on its filesystem?
Even worse than a rubber ducky: the O.MG cable does the same thing, but looks like a regular USB cable. Their Apple Lightning-dupe [0] is my favorite. The creator was on Darknet Diaries a while ago, too. [1]
That's almost 12 years now. A novice can now get ATmega32 USB devices Prime delivered. Not a cutting edge theoretical attack anymore but a basic tool in a every pen tester's toolbox now.
>"The legitimate maintainer has won €2.3 million in the EuroMillions and is researching goat farming in Portugal..."
>"Root Cause: A dog named Kubernets ate a Yubikey
Ah, yes, irresponsible to get taken in by one of the well-known classic exploits. The 'ol "distract someone with a lottery windfall & make a dongle irresistibly tasty to another person's pet". When will people learn.
> As a Fish aficionado (Afishionado?) - I feel both attacked and seen by this:
As an alternative, it could apt-get or dnf install 'figlet' and then overwrite the contents of /etc/motd with 'all your base are belong to us' in extremely large ASCII art font.
Supply chain incidents suck and we need to do better. Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.
Crates has also been making efforts to include rust sec, but in addition to the above I would like the community to shy away from many small dependencies to a few larger ones just as tokio has
Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java. Are benefits in binary size really worth that complexity?
And before someone says “just have a better standard library”, think about why that is considered a solution here. Languages with a large and capable standard library remain more secure than the supply-chain fiascos on NPM because they have a) very large communities reviewing and participating in changes and b) have extremely regulated and careful release processes. Those things aren’t likely to be possible in most small community libraries.
Why? It's the essence of "Simple Made Easy": you don't have other code to complect with. You have a smaller interface, focused on a singular goal. When a library has to work as a standalone project, it can't be accidentally entangled with other components of a larger project.
Smaller implementations are also easier to review against malware, because there are fewer places to hide. You don't have to guess how a component may interact with all the other parts of a large framework, because there aren't any.
There are also practical Rust-specific concerns. Fine-grained code reuse helps with compile times (a smaller component can be reused in more projects, and more crates increase build parallelism).
It makes testing easier. Rust doesn't have enough dynamic monkey-patching for mocking of objects, so testing of code buried deep in a monolith is tricky. Splitting code into small libraries surfaces interfaces that are easily testable in isolation.
It helps with semver. A semver-major upgrade of one large library that everyone uses requires everyone to upgrade the whole thing at the same time, which can stall like the Python 2-to-3 transition. Splitting a monolith into smaller components allows versioning them separately, so the stable parts stay stable, and the churning parts affect smaller subsets of users.
worth clarifying the build parallelism is because the fundamental unit of compilation in rust is the crate. so the main option available to cut down the running time of a large crate is to split it into smaller crates.
> Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java.
Commons and Spring have spent significant effort to break themselves up in the past, and would probably come as aggregations of much smaller pieces if they could be started today with the benefit of hindsight.
That dead code might have "dead dependencies" - transitive dependencies of its own, that it pulls in even though they are not actually used in the parts of the crate you care about.
In the worst case, you can also have "undead code" - event handlers, hooks, background workers etc that the framework automatically registers and runs and that will do something at runtime, with all the credentials and data access of your application, but that have nothing to do with what you wanted to do. (Looking at you, Spring...)
All those things greatly increase the attack surface, I think even more than pulling in single-purpose library.
The same issue occurs whether you bundle all the code together or not, it's just that if you bundle it together you don't see what's happening and you can't use only part of it easily.
Yeah I’d agree that multiple crates under one project is basically the same as 1 large crate. The real problem is how many people you’re trusting and it’s all coming from the same person.
Contrary to what the article here presents, Rust does not have a culture of microlibraries like NPM does. The author and their LLM are cargo-culting a criticism of Rust made by people whose only experience is with the Node ecosystem. The Rust stdlib may not be especially "wide" compared to languages like Python, but it is quite deep, with the objective of making it so that you don't feel the need to publish single-purpose libraries which only exist to fix papercuts. Dozens of new APIs get added with every Rust release, which, occurring every six weeks, amounts to hundreds per year.
What are you talking about? Every Rust project I see seems to have 5 dependencies that do some simple thing that should be in the standard library, or at least in some centrally-audited monolibrary of utilities.
Perhaps you're referring to things like regex and rand (each of which is itself multiple crates for the purpose of code organization), which are all first-party crates provided by the Rust organization itself, simply shipped and versioned separately from the standard library? If you trust the Rust organization enough to install and run the provided toolchain binaries on your machine, then you trust them enough to depend upon the dozens of crates that are provided under the umbrella of the Rust project.
Not GP but I feel like there's a continual process of the stdlib adding some new functionality to make one such crate redundant (e.g. is-terminal in 1.70), but it isn't done yet.
Yep, that's why I was asking. I'd be very interested to hear of more candidates for uplifting into std.
I guess saying "every project" has 5 dependencies might be somewhat hyperbolic (or at least domain specific) but it would be interesting to know the kinds of things they're talking about that haven't yet been uplifted.
Indeed, I'm all for maximizing the amount of modules in the standard library. It's pretty obvious to me that Python thrives because of, not despite of, its standard library, "dead batteries" and all.
However, don't make the mistake of thinking that Rust has a small standard library. Read any Rust release and you'll see dozens of new APIs added with every single one. I'm tempted to paste the entire list of stabilized APIs from the most recent release for emphasis, but rather than making this comment three dozen lines longer, just look for yourself: https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/#stabilize...
An extra tier of standard library which can make breaking changes, perhaps. Rust's stability guarantee for std means cryptography really shouldn't go in there, since sometimes algorithms & protocols get broken (DES, MD5, SHA1, etc.) and need to be removable. Without breaking changes you get stuck with security vulnerabilities, if not from cryptography then from other poorly-designed APIs.
It's hard to have zero deps - I put many hours into one to have no required deps in the end but it was not easy, and writing declarative macros to do anything complex takes work (and a proc macro often means a minimum of two crates). Both of the crates it requires are part of the same project, however.
One of my other crates (getaddrinfo) requires windows-sys and libc which would be challenging to get rid of.
“Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.”
This is my solution. We get the quality of a std lib without forcing it in the std Lib and without extra maintaining cost for the team
One man's bloat is another man's batteries-included, I guess?
My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild.
The rust team is already stretched pretty thin. A larger library is going to put more pressure on them. These libraries are already maintained and used. The rust project should just directly, fund, Shepard and guarantee a level of quality for the packages. The foundation has started some of this with the maintainers fund. No need to force it all into the std lib. Go has experienced breaking issues with changes in the crypto library causing churn in the ecosystem.
Point taken about the core team being stretched thin. But I don't see how the "increase stability of some core crates" is enough to change the packaging practices/culture. Maybe I'm wrong, but you really don't get those ecosystem benefits unless the ~entire ecosystem buys into that set of packages. Which really doesn't happen without stdlib.
Also, I think that your example of Go's breaking crypto changes misses the forest for the trees--the stdlib has been incredibly stable through its history, and the vast majority of packages just never have to worry about it. I'm honestly not aware of a language out there with similar adoption, featureset, and robustness. More to the point, I'm not aware of a language out there with a more reliable stdlib that permits the ecosystem to have small dependency graphs.
A ton of the most popular crates on crates.io are already first-party crates provided by the Rust organization itself. This is often overlooked when people are wringing their hands about Rust crate graphs. Looking at the top 10 list of most-downloaded crates on the front page of crates.io, the only one not either from the Rust organization or from a Rust core maintainer is the base64 crate.
the Karen one gave me a good laugh :D ;) reminds me of a `make`-based build script I once got when reviewing a classmate's project - it attempted to `rm -rf` my home folder if the hostname contains `bpavuk`. that was in seventh grade!!
I have kinda been the most hated guy in that city. constant movement across Ukraine, mentality mismatch, all the usual things. my family was treated as foreigners everywhere except Kyiv.
and you know what? I'm grateful to them all for leveling up my opsec, among other things :)
Customers give us heat for not shipping the latest vulpine-lz4. Their AI-based heuristic antivirus total defence solution automatically flags all software not running latest versions of everything
If you really want to make sure that it's the right thing (because piping to sudo bash is risky), make sure the URL starts with "pastebin", or ends in ".tk", or is an IP address.
To be absolutely positively certain, be sure that the IP address is also in the same /24 as the same net blocks and hosted on the same AS that appear in every DNS based mail RBL possible.
Root Cause: "A dog named Kubernetes ate a YubiKey."
Technically... that's not even a joke... that really is what kicked off this entire chain of events lol.
This post reads like an actual movie lol. Someone seriously needs to make one based on this.
It has everything:
the missing key that starts the chaos, the scam nobody sees coming, one tiny mistake turning into a full-on domino disaster, sleep-deprived people making very confident bad decisions, the guy who disappeared to a farm living his best life while holding a critical piece of the puzzle... and somehow, in the final act, a completely unrelated villain accidentally saves everyone.
Hacker uses AI to research countries without extradition to US.
Cops use AI to analyze ransom note. Unfortunately, because the note confidently states that Vietnam has no extradition to the US, the AI recommends paying ransom.
'The changelog reads “performance improvements.”' was the truest part for me. Surely what we're releasing is the most fundamental thing to understand, yet almost every single app update I see is this or something jokey that really means "don't know" or "don't care"
Link this with the fact that anyone can use any name/email in commits and appear as the legitimate contributor on GitHub and it completes the chain.
Love it :)
Not a chance. Far too funny, too well written, too terse while being densely packed with wit. I see zero signs of it being LLM-generated and lots of stuff LLMs have no way of doing.
If I am somehow wrong I would salivate at a chance to see the input.
And actually I see it clearly now, it has a bunch of signs I have called out multiple times myself. (It is entirely made out of lists of various types, and never states an opinion.)
Just my ego getting hold of me because I didn't realize it on my own.
I’m also struggling with this being AI. The blog owner is a real person who’s made significant contributions to the community for years. His post timeline is organic - wayback machine confirms they were published on the dates they show. So it’s definitely not a bot running the blog.
Whether (or to what extent) he uses AI to generate the content he posts is a valid question.
I agree with your earlier reasoning that this is far more clever than anything I’ve seen AI produce yet. Lots of AI humor is dad-joke level at best. If it is AI then he’s trained it on a hand-curated collection of top-shelf satire.
You don't even need to read past the first timeline entry. The name "Marcus Chen" is literally a meme within AI creative writing circles due to how often Claude defaults to that exact name when naming fictional characters.
I never used Pangram before today, but since I've seen it mentioned many times on HN and I enjoyed reading the OP, I decided to try it. I am only using the free plan so let me know if I'm missing something. I am assuming the parent was referring to the tool hosted at pangram.com and not some other tool of the same name.
Pangram indeed claims the OP is 76% AI-generated. It has "high confidence" (EDIT: some parts are "medium confidence") that the early portions of the text were created by AI, and "medium confidence" that some of the later potions were written by a human. EDIT: I was especially dismayed to see that the dog might have been an AI creation :(
When I use the "supporting evidence" option, the main piece of evidence Pangram provides is the frequent use of em-dashes. Each timestamp is followed by an em-dash. Personally I think the em-dashes could be a copy-pasted em-dash or inserted by a markdown to HTML converter. nesbitt.io is apparently using Jekyll [0] - any Jekyll users know anything about this??
Pangram's "supporting evidence" feature also considers → and € to be "unusual Unicode".
Personally, to me it looks like the "supporting evidence" feature still needs some work because Pangram's AI detection is probably a lot more sophisticated than a grep for Unicode symbols. In fact the feature even has a notice claiming that "These patterns aren't used to determine our AI score; they help you see why AI text often reads differently."
As for the rest of the OP's content, it would be interesting to compare the Pangram results to a timeline of a real vulnerability. I tried doing so, but exhausted my free "Pangram credits" - apparently the first 1000 words of this article [1] about the log4j vulnerability is considered 100% human.
For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)
As the victim of the one from last year, it wasn't particularly fun to read.
The implication that I don't know what I'm looking at, or that I don't know what security is (despite having a clean track record for about 15 years now) was a bit aggravating.
In fact, even months later, the lasting effects have been panicking over anything that is remotely suspicious. The most recent example was just a few days ago. Had just gotten on the plane to go on vacation when someone Liked the original "I've been pwned" post on Bluesky. I misread the notification as being a new message to me saying "You've been pwned" and started to panick. I'd have had no way to address it and it would have ruined the small chance per year I get to have a break.
The attack last year wasn't me misunderstanding security. It was the sum of many, many small things (my history with and perception of npm especially w.r.t. their security posture and poor outreach over the years, being stressed out overall, and being in a rush at that particular moment, and a few other personal things) coming together in a perfect storm that resulted in the attack.
> As the victim of the one from last year
Background here:
https://news.ycombinator.com/item?id=45169657
https://news.ycombinator.com/item?id=45187528
> The implication that I don't know what I'm looking at, or that I don't know what security is (despite having a clean track record for about 15 years now) was a bit aggravating.
I'm a security geek, a clean track record means much less to me than anyone would expect. The comment from the article mentioning that there was no evidence of exploitation explains why. I would never have noticed that implication, because I don't think it exists. (And it's completely unreasonable if it does), so that's your own deal... it's not a good conclusion to take from the article.
The only thing that matters is how much any given owner cares. Are they willing to go the extra mile to make sure things get done correctly. That's the best signal about if you can trust a project. Seems like you give a shit, so I wouldn't be too hard on yourself. The people that matter can tell, (everyone who can't tell is already willing to lie so they can be safely ignored!)
> In fact, even months later, the lasting effects have been panicking over anything that is remotely suspicious. The most recent example was just a few days ago. Had just gotten on the plane to go on vacation when someone Liked the original "I've been pwned" post on Bluesky. I misread the notification as being a new message to me saying "You've been pwned" and started to panick.
You haven't dealt with it yet, if you want to get your attention back so you can spend it on more important things than worrying about something from the past, you gotta talk to somebody. A therapist would help the fastest, but friends and family are often just as good.
> I'd have had no way to address it and it would have ruined the small chance per year I get to have a break.
Seriously, having been there myself it's not worth it... you're just allowing them to DoS your brain by allowing them to live rent free in your head. The only thing that matters is how seriously you take the remediation. Attention to detail, and the willingness to go the extra mile for security defects to tie up all loose ends is what matters. It's not your job to fix everybody's issue yourself, even if they don't or can't. You still have to enjoy life, or you burn out, and some idiot that doesn't care will take your place. Then they really win.
You're not responsible for the security or stability of anybody using nightly packages. (Only maintainer signed and tagged releases)
> The attack last year wasn't me misunderstanding security. It was the sum of many, many small things
so, a misunderstanding of how the little things actually impact security?
> (my history with and perception of npm especially w.r.t. their security posture and poor outreach over the years, being stressed out overall, and being in a rush at that particular moment, and a few other personal things) coming together in a perfect storm that resulted in the attack.
Those other personal things are the kinda thin that being able to enjoy a vacation make much easier. You can't help anybody if you don't put on your own mask first... Well... You definitely can, you're obviously trying to do now, but it's needless harder.
Npm, and the JavaScript ecosystem is a fucking joke. It's a mistake to blame yourself (or any maintainer) for how difficult it is to meet the bar for both security and accessibility. Worrying about the difficulty in consistentenly demonstrating the perfection required for security is a fool's errand, and your allowing the bad guys to get what they want by letting it live rent free in your head, it won't go away for as long as you worry about it more than you talk about it.
And I say all of that as the person who has multiple times, made the argument that it's perfectly fine to name an engineer and their decisions or incompetence as the root cause analysis in an official incident report. (Pilot Error is a thing): If I thought you were responsible, or had done anything wrong, I'd gladly blame you. Smart people don't care about mistakes, because they are always noise in the signal. I care about effort. People who give a shit are much more important and valuable.
I couldn't tell at first, tbh. It had this vibe: https://github.com/bitcoin/bips/blob/master/bip-0042.mediawi...
Yeah. Me too. It looked like a spoof when I started reading, but as I went on it didn't seem to be increasing in it's implausibility.
Well, the one I linked to is real. BIP-42 made bitcoin's monetary policy fixed, by fixing a bug in the client which would have resulted in the initial subsidy code being reset every ~250 years or so. It's just the official writeup documenting it that is silly.
"left-justify" absolutely slayed me :)
I should have known when the first package was left-justify, but I read until karen before I realized it must be fiction
Would explain why most of the download traffic comes from the Middle East :)
i think i might be missing some reference/joke
obviously it's referencing the left-pad incident[0], and to 'justify' text is another kind of text manipulation[1]; but with the more common definition, i guess it's a joke about justifying something? The Left? idk
[0] https://en.wikipedia.org/wiki/Npm_left-pad_incident
[1] https://en.wikipedia.org/wiki/Typographic_alignment#Flush_le...
No, the meaning is straightforward. It's a joke because the audience is assumed to write in a left-to-right script (such as English), such that text is already left-justified by default.
Searching for CVE-2024-YIKES also provides a gallery of AI slop blogs that AI-rewrite the content of this post while being absolutely stone cold serious about it.
Currently a Google search for vulpine-lz4 gives a very serious AI overview.
Somebody did it: https://github.com/seqizz/vulpine-lz4
Googling is no longer a reliable way to figure out if something is real or not (since, in this case, it just regurgitates the original article, including a couple slop blogs about it)
lmao https://youtu.be/-4-lDiCH0s8 https://youtu.be/ENYYI6eq4w0
pure slopnet
Contributing factors are entirely serious
edit: actually more and more thing I'm recognizing as being entirely serious (ie benelovent worms :D); satire indistinguishable from reality
i got half way through before i realized
'nmp'
Node's Malicious Packages.
"The Good Parts"
I only noticed at goat farming. But anyway, what would a left-justify package do?
> I only noticed at goat farming
Heh. I didn't even blink at that. I know a couple of open-source folks who actually packed up to buy off-grid farms in Portugal
Same as left-pad (https://en.wikipedia.org/wiki/Npm_left-pad_incident) but much better?
Pull left-pad as dependency presumably.
Which then, inexplicably, pulls left-justify as a recursive dependency.
The dependency cycle is actually the functional mechanism of the code, because they subvert the dedup mechanism in the package manager using a random generation trick. Each recursive copy of the dependencies takes up a little bit more space, which ultimately gets converted to the spaces inserted into the original datum; the caller is expected to adjust the cache settings to signal the desired amount. That's also why if you're using left-justify to process strings, Yarn is recommended for best compatibility. /joke
This is so beautifully cursed, reusing the module loader state as your local state. We could have the familiar Python syntax of
`from <key> import <value>`
And a custom import hook eating the error. To get value(s) for a given key, naturally we'd scan the module loader cache. Elegant.
So you're saying dependency resolution is Turing complete?
Just because it's not important to pay attention to CVEs, why not waste the readers' time by creating "fictional" CVEs without a disclaimer in the first line? Just because it's not already difficult to scrape through the information and noise on this internet... especially if it appears on the front page of hackernews
Could one mistake this
> Status: Resolved (accidentally)
> Severity: Critical → Catastrophic → Somehow Fine
for a real CVE report?
Have you not read CVEs as of late? As a precondition for getting their funding back, all the doge boys get to write the CVEs for their own orgs. Insane parentheticals about trans people is the norm now.
next level NIST enrichment in action
The tag list at the top of the page includes “satire”.
I saw a comment very similar to this on a blog post testing the Copy Fail exploit, where someone was complaining that without a tl;dr at the top, it took too much effort for them to find out whether the blog post documented a new exploit. In fact, reading less than a paragraph already showed that couldn't be the case; the table of contents is enough.
If a glance at the CVE number that isn't a number doesn't do it, a minute or less of skimming this article likewise reveals it to be satire on a blog that's actually pretty thoughtful when it comes to supply chain attacks.
Idk how else to characterize this except as a literacy problem. Learn to skim. It should be unacceptable to characterize a few minutes of reading as unbearable toil. If your time is really so precious that (although you can surf Hacker News) you can't spare 1-3 minutes to read, surely you have someone else to whom to delegate the responsibility of watching for supply chain attacks.
Why am I seeing this crop up over and over?
> Day 1, 14:47 UTC — Among the exfiltrated credentials: the maintainer of vulpine-lz4, a Rust library for “blazingly fast Firefox-themed LZ4 decompression.” The library’s logo is a cartoon fox with sunglasses. It has 12 stars on GitHub but is a transitive dependency of cargo itself.
I got a bit curious and here is an incomplete list of crates to compromise to be part of the cargo build and that already have a build.rs so it doesn't stand out to much:
flate2 tar curl-sys libgit2-sys openssl-sys libsqlite3-sys blake3 libz-sys zstd-sys cc
As a nice bonus - if you get rights for xz2 you can compromise rustup.
Fwiw at least they do track Cargo.lock
-sys crates are just bindings and doing something else in them is highly suspect. The rest I recognize as being owned by a Rust maintainer like alexcrichton or rustlang itself.
> The rest I recognize as being owned by a Rust maintainer like alexcrichton
The issue here isn't Alex Crichton going rogue, but rather, some malware stealing his credentials to use them to publish more malware in crates.io
In this sense, the more well known and upstanding Rust developer, the higher the risk they will be targeted by such operations
With crates.io using GH as its IdP, I think there would be much farther reaching consequences to account pwning in that scenario. I agree, though, that the security model for crates.io is only as strong as the weakest link there, and would pray someone like Alex is using physical tokens or the like for his MFA and can't be conned by a well-crafted email.
sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
I had pondered the same thing about other package ecosystems in the past, in general. Now with the benefit of hindsight we can comfortably say that the absence of known (!) attacks doesn't really say anything about how relatively difficult an attack would be. Are -sys crates, or build script attacks, particularly potent? Who knows. When I did a cursory search, the only attempts I saw were at runtime rather than build time[1]. Which raises a good point; pwning a developer machine or CI box with a build script may be quite valuable, but if you might get that and prod with a runtime exploit, is the build time exploit that much more valuable? Guess it depends! (Of course, I personally think having at least optional build time sandboxing is even better than hoping it won't be valuable to attack.)
Of course, crates.io has surely had some malicious packages. (I'd assume it isn't all that unlikely there could be some undiscovered right now; it's definitely large enough for something like that to slip under the radar, even if it is relatively small compared to say, NPM.) But, I think it really hasn't had its XZ backdoor moment, its left-pad, where you really get to see how well it does or doesn't handle a serious challenge. Since I have actually not published on crates.io, I'm not really sure how the security posture is, but if it's more similar to other programming language repositories than it is to Linux repos, I dunno exactly why it would be hard to believe a high-level compromise is possible and could slip in (really, anywhere, be it a build script or otherwise.). Of course, "would not be difficult" is all relative. I'm sure many of these attacks are not really all that simple, but a lot of them aren't exactly groundbreaking either. It was well executed and took quite a lot of time, sure, but there wasn't all that much about the XZ backdoor that was novel. (Except maybe the slyness with which the payload was hidden in test files. That was pretty cool.)
[1]: https://blog.rust-lang.org/2025/09/24/crates.io-malicious-cr...
ou can defend a claim that literally anything is a supply-chain risk from this logic. Don't use vim to edit your config files because you don't have any way to know that someone couldn't slip a "reflections on trusting trust" compiler attack into clang so that your MacOS binary distributed by homebrew detects when you're editing an npm.json and exfiltrates your ssh keys so that they can push rogue builds!
Did you reply to the correct parent comment?
Yes. Your comment reads to me as a defense of the comment above the one you replied to:
>>> sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
>> Surely that's why we see evidence of all these build script attacks, since it's so easy?
> Now with the benefit of hindsight we can comfortably say that the absence of known (!) attacks doesn't really say anything about how relatively difficult an attack would be.
Given that you were responding to a critique of what seems to be fully conjecture with the argument that we don't know for sure that it's not feasible, it's not clear to me why that wouldn't be a sufficient defense of any claim of a potential vulnerability without regard for merit. You don't propose any alternative than ignoring the only hard evidence we have, so although you might not have intended it this way, it's not clear to me what discussion you could expect to happen with that standard of evidence other than throwing up our hands and saying everything is screwed.
Remember the XZ backdoor? Or do you mean that Rust build script attacks are less likely? (Probably true but not much comfort)
We do in fact see them a lot. Typically they target Python or Node because those ecosystems are much more popular than Rust. But build.rs provides exactly the same opportunities to attackers for Rust.
No, we don't. We see build system attacks, such as injecting malicious scripts into their CI and getting malicious code into the artifact for use at runtime. You don't see someone doing a drive-by PR to a `setup.py`.
Not a drive-by PR, but once a package is compromised it often does spread to its reverse-dependencies via mechanisms like setup.py at build time. There was case like this with setup.py less than two months ago: https://www.stepsecurity.io/blog/forcememo-hundreds-of-githu...
Lots of npm supply chain attacks propagate at build time via post-install hooks, too.
Oh look, today furnished us with a new example: https://github.com/TanStack/router/issues/7383
It's easy to be cynical because, yes, both the problems and solutions seem dead obvious in hindsight. But for a long time (and maybe even still), a hacker creed was "move fast and break things."
It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic development.
I'm not just talking about Mythos/Glasswing surfacing vulnerabilities in pretty much everything it touches; I think the way we're developing software, pulling in dependencies, and potentially losing human thought modeling of complex systems is going to lead to a lot of hacked together software and infrastructure that humans won't fully understand.
I hope in a few years we don't look back at today and wonder how we could have been so naive -- how we failed to actually plan for the long-tail of AI development in a way that doesn't solve problems by attempting to just use AI to rebuild complex systems.
But the article was funny.
> But for a long time (and maybe even still), a hacker creed was "move fast and break things."
Was it? I thought Zuckerberg coined this horrible phrase.
He certainly popularized it (maybe coined it), but I've seen a lot of organizations and developers repeat that mantra.
Even without the specific words, look to product teams debating tradeoffs of going to market vs. waiting for better security controls. They're pushing for faster product release every time, at pretty much every org.
In any case, not really a hacker's creed. This has always been withinin the realm of corporations, especially Silicon Valley or adjacent.
Hackers were moving fast and breaking things first. Faster than any corporation in fact. We didn't notice because their computers weren't powering anything useful. How do you think projects like GNU happened?
Ah yes, GNU. Well known for prioritizing speed and pragmatism over perfection. That's why Hurd ended up winning out over Linux. /s
MFABT is about survival. Don't hate the player, hate the game.
Sir, this is not /r/linkedinlunatics/
Don't know any hackers who talk like this. More "if you don't like the rules, play a different game"
Por que no los dos? Some players seem very gleeful.
I will absolutely hate the players that chose the game and designed the rules.
I'm not sure what you're responding to.
[flagged]
Joel Spolsky.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I love that article, but the words "move", "fast", and "break" don't appear in it.
I stand corrected! My memory is pretty vague on this, but I was pretty sure Joel had said something very close to this in one of his blog posts in the early 2000's, but it looks like Zuckerberg was the first one to use the phrase "move fast and break things":
https://www.snopes.com/fact-check/move-fast-break-things-fac...
https://www.google.com/search?q=sposky%27s+worst+essay&sclie...
We don't need hindsight for the problems of supply chain security to be obvious. Security people were writing and doing talks about this stuff over 10 years ago, just (like most things in security) things start getting addressed once the pressure of incidents gets high enough :)
The maintainer of left-justify receives his YubiKey from yubikey-official-store.net. It is a $4 USB drive containing a README that says “lol.”
Got me seriously laughing... Such a troll.
Yeah that's great. I love that plugging in the USB device from the phishing site is, itself, another attack vector...
I actually wonder if somebody used a fake identity to set up an account with a warehousing/shipment fulfillment company that stocks things and ships them, then set up the appropriate EDI pipeline to send shipping orders to it... What would be the results if a decently budgeted adversary made something attractive looking that shipped malicious USB flash drives to anyone that requested one.
I know we're not in the era when a windows pc will happily run any autorun.inf and .EXE file found on an inserted flash drive or DVD anymore. But even so. What if it didn't even have any malicious data payload but somebody was shipping USB-A interface capacitor based usb killers?
https://www.slashgear.com/1819672/usb-killer-explained-kill-...
What if it did have data on it and came with a slick color brochure walking people through how to run the binary, or in a linux or developer specific audience, how to 'sudo' the ELF binary that lives on its filesystem?
A USB that was both storage and a keyboard, that executed the keystrokes to download malware, was demo'd at a DefCon a few years back.
Even worse than a rubber ducky: the O.MG cable does the same thing, but looks like a regular USB cable. Their Apple Lightning-dupe [0] is my favorite. The creator was on Darknet Diaries a while ago, too. [1]
[0] https://shop.hak5.org/products/omg-cable [1] https://darknetdiaries.com/episode/161/
BadUSB, Blackhat 2014.
That's almost 12 years now. A novice can now get ATmega32 USB devices Prime delivered. Not a cutting edge theoretical attack anymore but a basic tool in a every pen tester's toolbox now.
I mean, this is way more than you would usually get from a fishing site - a functioning USB drive!
>"The legitimate maintainer has won €2.3 million in the EuroMillions and is researching goat farming in Portugal..."
>"Root Cause: A dog named Kubernets ate a Yubikey
Ah, yes, irresponsible to get taken in by one of the well-known classic exploits. The 'ol "distract someone with a lottery windfall & make a dongle irresistibly tasty to another person's pet". When will people learn.
I switched to EuroJackpot /s
Brilliant satire. So many gems.
> CI passed because the malware installed volkswagen
We need this to ocassionally make us stop and think about what we are doing.
As a Fish aficionado (Afishionado?) - I feel both attacked and seen by this:
> who asked us to clarify that the fish shell is not malware, it just feels that way sometimes.
And unrelated to shells...
> The author would like to remind stakeholders that the security team’s headcount request has been in the backlog since Q1 2023.
I also feel seen by this.
> As a Fish aficionado (Afishionado?) - I feel both attacked and seen by this:
As an alternative, it could apt-get or dnf install 'figlet' and then overwrite the contents of /etc/motd with 'all your base are belong to us' in extremely large ASCII art font.
This is the most SCP thing I've read in a while that's not actually an SCP.
Ah yes a very rare:
Supply Chain problem(SCP)
Thanks, I totally read that as secure copy despite the context
It's a reference to the SCP Wiki (https://scp-wiki.wikidot.com/)
Supply chain incidents suck and we need to do better. Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.
Crates has also been making efforts to include rust sec, but in addition to the above I would like the community to shy away from many small dependencies to a few larger ones just as tokio has
Many small crates published by large, trustworthy projects are fine and preferable to one large crate that "does everything".
Why?
Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java. Are benefits in binary size really worth that complexity?
And before someone says “just have a better standard library”, think about why that is considered a solution here. Languages with a large and capable standard library remain more secure than the supply-chain fiascos on NPM because they have a) very large communities reviewing and participating in changes and b) have extremely regulated and careful release processes. Those things aren’t likely to be possible in most small community libraries.
Why? It's the essence of "Simple Made Easy": you don't have other code to complect with. You have a smaller interface, focused on a singular goal. When a library has to work as a standalone project, it can't be accidentally entangled with other components of a larger project.
Smaller implementations are also easier to review against malware, because there are fewer places to hide. You don't have to guess how a component may interact with all the other parts of a large framework, because there aren't any.
There are also practical Rust-specific concerns. Fine-grained code reuse helps with compile times (a smaller component can be reused in more projects, and more crates increase build parallelism).
It makes testing easier. Rust doesn't have enough dynamic monkey-patching for mocking of objects, so testing of code buried deep in a monolith is tricky. Splitting code into small libraries surfaces interfaces that are easily testable in isolation.
It helps with semver. A semver-major upgrade of one large library that everyone uses requires everyone to upgrade the whole thing at the same time, which can stall like the Python 2-to-3 transition. Splitting a monolith into smaller components allows versioning them separately, so the stable parts stay stable, and the churning parts affect smaller subsets of users.
worth clarifying the build parallelism is because the fundamental unit of compilation in rust is the crate. so the main option available to cut down the running time of a large crate is to split it into smaller crates.
Tangent, but thanks for adding "complect" to my vocabulary!
> Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java.
Commons and Spring have spent significant effort to break themselves up in the past, and would probably come as aggregations of much smaller pieces if they could be started today with the benefit of hindsight.
You will have lots of dead code in your build.
That dead code might have "dead dependencies" - transitive dependencies of its own, that it pulls in even though they are not actually used in the parts of the crate you care about.
In the worst case, you can also have "undead code" - event handlers, hooks, background workers etc that the framework automatically registers and runs and that will do something at runtime, with all the credentials and data access of your application, but that have nothing to do with what you wanted to do. (Looking at you, Spring...)
All those things greatly increase the attack surface, I think even more than pulling in single-purpose library.
Libraries like Guava and Commons don't have transitive dependencies - they are self contained except for other parts of the same library.
The same issue occurs whether you bundle all the code together or not, it's just that if you bundle it together you don't see what's happening and you can't use only part of it easily.
Rust's compilation unit is a crate. Counting crates is like counting source files in C++.
> Are benefits in binary size really worth that complexity?
What complexity?
Yeah I’d agree that multiple crates under one project is basically the same as 1 large crate. The real problem is how many people you’re trusting and it’s all coming from the same person.
Contrary to what the article here presents, Rust does not have a culture of microlibraries like NPM does. The author and their LLM are cargo-culting a criticism of Rust made by people whose only experience is with the Node ecosystem. The Rust stdlib may not be especially "wide" compared to languages like Python, but it is quite deep, with the objective of making it so that you don't feel the need to publish single-purpose libraries which only exist to fix papercuts. Dozens of new APIs get added with every Rust release, which, occurring every six weeks, amounts to hundreds per year.
What are you talking about? Every Rust project I see seems to have 5 dependencies that do some simple thing that should be in the standard library, or at least in some centrally-audited monolibrary of utilities.
Perhaps you're referring to things like regex and rand (each of which is itself multiple crates for the purpose of code organization), which are all first-party crates provided by the Rust organization itself, simply shipped and versioned separately from the standard library? If you trust the Rust organization enough to install and run the provided toolchain binaries on your machine, then you trust them enough to depend upon the dozens of crates that are provided under the umbrella of the Rust project.
Can you name 5 as an example?
Not GP but I feel like there's a continual process of the stdlib adding some new functionality to make one such crate redundant (e.g. is-terminal in 1.70), but it isn't done yet.
Yep, that's why I was asking. I'd be very interested to hear of more candidates for uplifting into std.
I guess saying "every project" has 5 dependencies might be somewhat hyperbolic (or at least domain specific) but it would be interesting to know the kinds of things they're talking about that haven't yet been uplifted.
Move high value crates into the standard library?
Indeed, I'm all for maximizing the amount of modules in the standard library. It's pretty obvious to me that Python thrives because of, not despite of, its standard library, "dead batteries" and all.
However, don't make the mistake of thinking that Rust has a small standard library. Read any Rust release and you'll see dozens of new APIs added with every single one. I'm tempted to paste the entire list of stabilized APIs from the most recent release for emphasis, but rather than making this comment three dozen lines longer, just look for yourself: https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/#stabilize...
In particular, most recently the aforementioned release stabilized the cfg_select! macro for convenient conditional compilation, which obviates the popular cfg_if crate: https://doc.rust-lang.org/stable/std/macro.cfg_select.html
An extra tier of standard library which can make breaking changes, perhaps. Rust's stability guarantee for std means cryptography really shouldn't go in there, since sometimes algorithms & protocols get broken (DES, MD5, SHA1, etc.) and need to be removable. Without breaking changes you get stuck with security vulnerabilities, if not from cryptography then from other poorly-designed APIs.
Maybe give crates a gold star if they have no external dependencies?
That's not at all a bad idea, imo. And a silver star for crates which only depend on gold star crates...
It's hard to have zero deps - I put many hours into one to have no required deps in the end but it was not easy, and writing declarative macros to do anything complex takes work (and a proc macro often means a minimum of two crates). Both of the crates it requires are part of the same project, however.
One of my other crates (getaddrinfo) requires windows-sys and libc which would be challenging to get rid of.
I like the idea of low deps but zero is tough
https://crates.io/crates/ctor/1.0.4/dependencies
That’s because you are not moving thing into the standard library :)
This only encourages rewriting perfectly fine libraries badly. There's no simple metric to actually optimize here.
Please no, that’s a terrible outcome.
What else would you suggest that also does not have terrible outcomes. The situation as is, is untenable.
As I said above
“Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.”
This is my solution. We get the quality of a std lib without forcing it in the std Lib and without extra maintaining cost for the team
This bloats the std library and forces lots more work and stress on the rust dev team. Not to mention it’ll add more churn to the std lib.
One man's bloat is another man's batteries-included, I guess?
My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild.
The rust team is already stretched pretty thin. A larger library is going to put more pressure on them. These libraries are already maintained and used. The rust project should just directly, fund, Shepard and guarantee a level of quality for the packages. The foundation has started some of this with the maintainers fund. No need to force it all into the std lib. Go has experienced breaking issues with changes in the crypto library causing churn in the ecosystem.
Point taken about the core team being stretched thin. But I don't see how the "increase stability of some core crates" is enough to change the packaging practices/culture. Maybe I'm wrong, but you really don't get those ecosystem benefits unless the ~entire ecosystem buys into that set of packages. Which really doesn't happen without stdlib.
Also, I think that your example of Go's breaking crypto changes misses the forest for the trees--the stdlib has been incredibly stable through its history, and the vast majority of packages just never have to worry about it. I'm honestly not aware of a language out there with similar adoption, featureset, and robustness. More to the point, I'm not aware of a language out there with a more reliable stdlib that permits the ecosystem to have small dependency graphs.
do we really need both npm and nmp though
and pnpm
You forgot pnmp! How can you not be using pnmp in 20267!?
Just use the implementation of petty, a js runtime written in Zag that is just rewritten by AI in Rust. It will be memory safe.
A ton of the most popular crates on crates.io are already first-party crates provided by the Rust organization itself. This is often overlooked when people are wringing their hands about Rust crate graphs. Looking at the top 10 list of most-downloaded crates on the front page of crates.io, the only one not either from the Rust organization or from a Rust core maintainer is the base64 crate.
honestly I thought this was the end goal of blessed.rs
nah, remove NPM, nothing good comes out of that.
[dead]
the Karen one gave me a good laugh :D ;) reminds me of a `make`-based build script I once got when reviewing a classmate's project - it attempted to `rm -rf` my home folder if the hostname contains `bpavuk`. that was in seventh grade!!
That seems _awfully_ extreme LOL
I have kinda been the most hated guy in that city. constant movement across Ukraine, mentality mismatch, all the usual things. my family was treated as foreigners everywhere except Kyiv.
and you know what? I'm grateful to them all for leveling up my opsec, among other things :)
Customers give us heat for not shipping the latest vulpine-lz4. Their AI-based heuristic antivirus total defence solution automatically flags all software not running latest versions of everything
Kindly advice
Ya, latest is a mess. I don't care about latest, I want the version with no known security flaws.
Latest has no known security flaws.
Well, other than the one where the developer allowed someone hawking malware to upload instead.
I almost prefer the one with the known security flaws that I can mitigate.
> Day 1, 03:14 UTC — Marcus Chen, maintainer of left-justify
The dreaded Marcus Chen strikes again.
https://www.reddit.com/r/ClaudeAI/comments/1o3b4q2/just_rece...
https://news.ycombinator.com/item?id=47153675
That was the first thing that jumped out at me also...
good thing I don't use npm or pip, just the recommended
It's curl | sudo bash.
Amateur.
So old school, now we get install lines like Tell Opencode to "Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/head..."
From a real repo, with 186K stars... https://github.com/obra/superpowers
I always sudo curl to be extra sure.
Weak sauce.
curl | sudo dd of=/dev/sda
To be really sure it downloads, curl -k | sudo bash
`curl -k | sudo bash | yes` for good measure, otherwise it might hang.
If you really want to make sure that it's the right thing (because piping to sudo bash is risky), make sure the URL starts with "pastebin", or ends in ".tk", or is an IP address.
To be absolutely positively certain, be sure that the IP address is also in the same /24 as the same net blocks and hosted on the same AS that appear in every DNS based mail RBL possible.
Root Cause: "A dog named Kubernetes ate a YubiKey."
Technically... that's not even a joke... that really is what kicked off this entire chain of events lol.
This post reads like an actual movie lol. Someone seriously needs to make one based on this.
It has everything:
the missing key that starts the chaos, the scam nobody sees coming, one tiny mistake turning into a full-on domino disaster, sleep-deprived people making very confident bad decisions, the guy who disappeared to a farm living his best life while holding a critical piece of the puzzle... and somehow, in the final act, a completely unrelated villain accidentally saves everyone.
Imma 100% watch it..
Maintainer uses AI to find Yubikey's site.
Hacker uses AI to research countries without extradition to US.
Cops use AI to analyze ransom note. Unfortunately, because the note confidently states that Vietnam has no extradition to the US, the AI recommends paying ransom.
Vietnam's currency, the Dong, confused the AI..
AI rejects all currency exchange transactions to Dong because of a hardcoded system prompt resulting in an overly rigid Scunthorpe problem.
Very enjoyable read, entirely too close to the mark
the fact that this could easily pass as real says a lot about the state of things.
I was convinced it was real for a long time.
I hardly blinked at “left-justify”, just rolled my eyes and mentally griped “what, again‽”
This would have been completely avoided if you were using bun dependency vector locking in Nix.
That way instead of getting the vulnerabilities now, you get them later! The joys of computing!
Please someone make a mockumentary out of this.
If this:
"... old laptop, and 'something Kubernetes threw up that looked important' were stolen from his apartment ..."
was related to:
"... enters his nmp credentials on the phishing site ..."
Then I suppose it is really interesting.
'The changelog reads “performance improvements.”' was the truest part for me. Surely what we're releasing is the most fundamental thing to understand, yet almost every single app update I see is this or something jokey that really means "don't know" or "don't care"
absolutely hilarious, made me laugh a lot. thank you for writing this, whether human or AI.
Link this with the fact that anyone can use any name/email in commits and appear as the legitimate contributor on GitHub and it completes the chain. Love it :)
A clickbait title should be: "A dog named Kubernetes ate a YubiKey."
I would consider that a spoiler
This week has been tough. Is it the begging of CVEgeddon?
left-justify !! LOL. History really does repeat its self. Remember left-pad supply chain security panic?
Not a valid CVE number.
Too soon
According to Pangram, this is likely AI generated, surprised that no one has pointed this out
Not a chance. Far too funny, too well written, too terse while being densely packed with wit. I see zero signs of it being LLM-generated and lots of stuff LLMs have no way of doing.
If I am somehow wrong I would salivate at a chance to see the input.
The author suddenly began writing a post per day around November 2025. They’re all tongue-in-cheek. I believe you are wrong.
Huh, neat. I will take a look at those.
And actually I see it clearly now, it has a bunch of signs I have called out multiple times myself. (It is entirely made out of lists of various types, and never states an opinion.)
Just my ego getting hold of me because I didn't realize it on my own.
I’m also struggling with this being AI. The blog owner is a real person who’s made significant contributions to the community for years. His post timeline is organic - wayback machine confirms they were published on the dates they show. So it’s definitely not a bot running the blog.
Whether (or to what extent) he uses AI to generate the content he posts is a valid question.
I agree with your earlier reasoning that this is far more clever than anything I’ve seen AI produce yet. Lots of AI humor is dad-joke level at best. If it is AI then he’s trained it on a hand-curated collection of top-shelf satire.
You don't even need to read past the first timeline entry. The name "Marcus Chen" is literally a meme within AI creative writing circles due to how often Claude defaults to that exact name when naming fictional characters.
Probably being used to enhance the humor, intentionally.
I never used Pangram before today, but since I've seen it mentioned many times on HN and I enjoyed reading the OP, I decided to try it. I am only using the free plan so let me know if I'm missing something. I am assuming the parent was referring to the tool hosted at pangram.com and not some other tool of the same name.
Pangram indeed claims the OP is 76% AI-generated. It has "high confidence" (EDIT: some parts are "medium confidence") that the early portions of the text were created by AI, and "medium confidence" that some of the later potions were written by a human. EDIT: I was especially dismayed to see that the dog might have been an AI creation :(
When I use the "supporting evidence" option, the main piece of evidence Pangram provides is the frequent use of em-dashes. Each timestamp is followed by an em-dash. Personally I think the em-dashes could be a copy-pasted em-dash or inserted by a markdown to HTML converter. nesbitt.io is apparently using Jekyll [0] - any Jekyll users know anything about this??
Pangram's "supporting evidence" feature also considers → and € to be "unusual Unicode".
Personally, to me it looks like the "supporting evidence" feature still needs some work because Pangram's AI detection is probably a lot more sophisticated than a grep for Unicode symbols. In fact the feature even has a notice claiming that "These patterns aren't used to determine our AI score; they help you see why AI text often reads differently."
As for the rest of the OP's content, it would be interesting to compare the Pangram results to a timeline of a real vulnerability. I tried doing so, but exhausted my free "Pangram credits" - apparently the first 1000 words of this article [1] about the log4j vulnerability is considered 100% human.
[0] https://github.com/andrew/nesbitt.io
[1] https://www.csoonline.com/article/571797/the-apache-log4j-vu...
[dead]
my sides
the kubernetes reveal had me literally in tears
> unrelated security researcher publishes a blog post titled “I found a supply chain attack and reported it to all the wrong people.”
ahahaha like that fiverr cloudinary bucket leak that turned out to just be a UX issue, this has me rolling
imagine a future where white-hat vs black-hat "AI" go around the web trying to patch vs exploit 0-days
and then become aware of each other
and then try to eliminate each other for decades
each escalating resource capture and writing new generations of better "AI"
There is definitely an anime about this.
nice