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.

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...

There is definitely an anime about this.

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.

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 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...

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.

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

That’s because you are not moving thing into the standard library :)

Which then, inexplicably, pulls left-justify as a recursive dependency.

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.

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.

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?

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?

MFABT is about survival. Don't hate the player, hate the game.

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...

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.

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.

> 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.

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?

Oh look, today furnished us with a new example: https://github.com/TanStack/router/issues/7383

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.