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 :)
> 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.
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.
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!!
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
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.
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.
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.
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
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 :)
'nmp'
Node's Malicious Packages.
I couldn't tell at first, tbh. It had this vibe: https://github.com/bitcoin/bips/blob/master/bip-0042.mediawi...
> 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
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.
MFABT is about survival. Don't hate the player, hate the game.
I'm not sure what you're responding to.
Por que no los dos? Some players seem very gleeful.
Don't know any hackers who talk like this. More "if you don't like the rules, play a different game"
I will absolutely hate the players that chose the game and designed the rules.
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...
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!!
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/)
the fact that this could easily pass as real says a lot about the state of things.
I hardly blinked at “left-justify”, just rolled my eyes and mentally griped “what, again‽”
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".
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.
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.
do we really need both npm and nmp though
and pnpm
nah, remove NPM, nothing good comes out of that.
Move high value crates into the standard library?
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.
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.
Maybe give crates a gold star if they have no external dependencies?
honestly I thought this was the end goal of blessed.rs
Very enjoyable read, entirely too close to the mark
good thing I don't use npm or pip, just the recommended
It's curl | sudo bash.
Amateur.
This would have been completely avoided if you were using bun dependency vector locking in Nix.
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.
absolutely hilarious, made me laugh a lot. thank you for writing this, whether human or AI.
This week has been tough. Is it the begging of CVEgeddon?
Too soon
> 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"