@antfu Thanks for your work to explore #pnpm catalogs. I agree that this is especially useful to document how and when to update certain dependencies.

Some are safe to change (testing and dev deps), and others require careful review (runtime production dependencies with access to sensitive data).

Looking forward to how this develops over time. This could create big improvements for #JavaScript and #TypeScript projects.

https://antfu.me/posts/categorize-deps

#web #webdev #frontend #npm

🔒 If you publish packages to the npm registry and haven't already seen its new Trusted Publisher feature, please do take a look at https://docs.npmjs.com/trusted-publishers

🎟️ It uses short-lived OIDC tokens to allow CI-based automation of signed publish-with-provenance.

📈 According to https://github.com/sxzz/npm-top-provenance I maintain 6 of the top 50 packages that use this feature, and those 6 packages combined have over 600 million downloads each month!

#OpenSource #NodeJS #npm

I'm a few days late to the party, but #npm still doing nothing to convince me it's a good idea. This is nuts. #security

https://www.koi.security/incident/shai-hulud-npm-supply-chain-attack-crowdstrike-tinycolor

Shai-Hulud: The novel self-replicating worm infecting hundreds of NPM packages

https://www.sysdig.com/blog/shai-hulud-the-novel-self-replicating-worm-infecting-hundreds-of-npm-packages

"Once executed, this novel worm — dubbed Shai-Hulud — steals credentials, exfiltrates them, and attempts to find additional NPM packages in which to copy itself. The malicious code also attempts to leak data on GitHub by making private repositories public."

#infoSec #NPM #dependencyHell

Novo ciberataque “Shai-Hulud” propaga-se como um verme e compromete 187 pacotes npm
🔗 https://tugatech.com.pt/t71903-novo-ciberataque-shai-hulud-propaga-se-como-um-verme-e-compromete-187-pacotes-npm

#API #ataque #cascata #CD #CI #ciberataque #Github #google #javascript #linkedin #malware #npm #phishing #riscos #segurança #servidor #software 

cross-posting my little rant about #npm #npmattack #javascript #typescript stuff here:

Random NPM thoughts of the day:

1. The primary NPM registry should be obsoleted entirely ASAP
2. JSR does not do anywhere near as much as it should, and it's probably too late to fix.
3. A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
4. All packages MUST be ESM (JSR ok here)
5. MUST include docstrings on all publicly-reachable interfaces.
6. MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
7. MUST have a non-trivial README.
8. MUST be tied to a PUBLIC repo.
9. MUST NOT have install scripts (yeah sorry, the fight's over)
10. MUST clearly include a license, even if the license is "source available, not open source". This restriction MUST NOT limit to OSI's ridiculous list.
11. MUST have a name that is scoped to its publishing user/org (@foo/bar)All of the above constraints MUST be checked at publish time.

Furthermore, the registry MUST provide the following, based on this:

1. Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
2. Autogenerated API docs.
3. Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.
4. Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
5. Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
6. Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queue, overridden by [tbd?staff?]
7. Y'all aren't gonna like this but: package installation should be reasonably throttled. Both to keep costs down, and to encourage people to do something less lazy than "I'm just going to install all 2k dependencies on CI every time I push a docs change". It's wasteful and harmful for many reasons.

I think that's all I got off the top of my head for now.

There's honestly a lot of stuff that could be done on the client side to make life better, too, and y'all know I have a ton of thoughts on that, but I wanted to rant about registries for a bit, esp now that the NPM registry is crumbling.

cross-posting my little rant about #npm #npmattack #javascript #typescript stuff here:

Random NPM thoughts of the day:

1. The primary NPM registry should be obsoleted entirely ASAP
2. JSR does not do anywhere near as much as it should, and it's probably too late to fix.
3. A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
4. All packages MUST be ESM (JSR ok here)
5. MUST include docstrings on all publicly-reachable interfaces.
6. MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
7. MUST have a non-trivial README.
8. MUST be tied to a PUBLIC repo.
9. MUST NOT have install scripts (yeah sorry, the fight's over)
10. MUST clearly include a license, even if the license is "source available, not open source". This restriction MUST NOT limit to OSI's ridiculous list.
11. MUST have a name that is scoped to its publishing user/org (@foo/bar)All of the above constraints MUST be checked at publish time.

Furthermore, the registry MUST provide the following, based on this:

1. Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
2. Autogenerated API docs.
3. Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.
4. Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
5. Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
6. Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queue, overridden by [tbd?staff?]
7. Y'all aren't gonna like this but: package installation should be reasonably throttled. Both to keep costs down, and to encourage people to do something less lazy than "I'm just going to install all 2k dependencies on CI every time I push a docs change". It's wasteful and harmful for many reasons.

I think that's all I got off the top of my head for now.

There's honestly a lot of stuff that could be done on the client side to make life better, too, and y'all know I have a ton of thoughts on that, but I wanted to rant about registries for a bit, esp now that the NPM registry is crumbling.

👨‍💻 The good news is that the industry will take stock of this event and finally come together to solve this issue, and it will never happen again... right? #npm

https://www.youtube.com/watch?v=QVqIx-Y8s-s

I'm not sure how I feel about Passkeys/WebAuthn yet. But as far as I understand the current npm situation with compromised packages could have been prevented with phishing resistant 2FA. Combined with trusted publishing [1] this should be a lot harder for malicious actors – at least for this attack vector.

#npm #security

[1] https://docs.npmjs.com/trusted-publishers

In light of the recent npm attack, does rust do better? Fundamentally the same could always happen.

Do we have anything in place, if not could we?

#rust #rustlang #npm #nodejs

In light of the recent npm attack, does rust do better? Fundamentally the same could always happen.

Do we have anything in place, if not could we?

#rust #rustlang #npm #nodejs

Oh no, not again... a meditation on #NPM supply chain attacks

https://tane.dev/2025/09/oh-no-not-again...-a-meditation-on-npm-supply-chain-attacks/

Oh #npm got hacked… or rather, a maintainer of packages like debug and chalk was a victim of a phishing attack 😱
https://tweakers.net/nieuws/238896/npm-packages-met-2-miljard-wekelijkse-downloads-zijn-met-malware-geinfecteerd.html

A bunch of packages published by qix in NPM just got backdoored it looks like. Obfuscated code was added like two hours ago. #threatintel #npm

Also, npm now supports trusted publishing: https://docs.npmjs.com/trusted-publishers

This means you don't need a static token in your CI/CD configuration anymore.

#npm #npmattack

Pro-tip for npm: rather than using a classic access token in your ~/.npmrc file, generate a granular access token that only has read permissions.

That way if something does compromise you, they only get access to the read token and cannot publish on your behalf.

#npm #npmattack

For example: https://www.npmjs.com/package/is-arrayish?activeTab=code

I think quite a few packages are impacted, potentially some very high volume ones. I gotta hop on a subway to make a plane though so it’s going to be hard for me to keep digging.

#threatintel #npm

A bunch of packages published by qix in NPM just got backdoored it looks like. Obfuscated code was added like two hours ago. #threatintel #npm

How many #npm packages have a .cursor or .claude folder in their source repo?

2/ i wrote a short-ish "note" over on The Blogging Site That Shall Not Be Named in an attempt to explain to the less technologically sophisticated people in the audience what just happened with the #nx / #npm supply chain attack.

* my simplified explanation: https://substack.com/profile/96801203-michel-de-cryptadamus/note/c-149738571
* for the trve heads with opinions on things like linux distros and the Rust programming language, Wiz wrote a much more thorough explanation: https://www.wiz.io/blog/s1ngularity-supply-chain-attack

#crypto #cryptocurrency #nodejs #node #threatintel #northkorea #lazarusgroup#DPRK #hackers #hacking #ethereum #claude #gemini