Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

81–90 of 796 posts

Re: NPM debug and chalk packages compromised

#81

Post by jvuygbbkuurx »

junon wrote: post #26
dboreham wrote: post #12

Earlier quoted context omitted.

Sorry to be dumb, but can you expand a bit on "2FA reset email..." so the rest of us know what not to do?

Ignore anything coming from npm you didn't expect. Don't click links, go to the website directly and address it there. That's what I should have done, and didn't because I was in a rush. Don't do security things when you're not fully awake, too. Lesson learned. The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things co…

Did they also phish the login password after clicking the link or did they already have it?

Re: NPM debug and chalk packages compromised

#82

Post by imiric »

rudedogg wrote: post #41
thewebguyd wrote: post #32

Earlier quoted context omitted.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser. I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.

To be fair, this is not a problem with the web itself, but with the Node ecosystem.

It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them.

Yes, this is more inconvenient and labor intensive, but the alternative is far riskier and worse for users.

The problem is with web developers themselves, who are often lazy, and prioritize their own development experience over their users'.

Re: NPM debug and chalk packages compromised

#83

Post by martypitt »

patates wrote: post #76
martypitt wrote: post #48

A super quick script to check the deps in your package-lock.json file is here[0]. [0]: https://gist.github.com/martypitt/0d50c350aa7f0fc73354754343...

aren't these already nuked and show up in the "npm audit" command?

Nice - that's even better - thanks! TIL.

Re: NPM debug and chalk packages compromised

#84

Post by tracker1 »

thewebguyd wrote: post #32
stathibus wrote: post #18

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

Worth mentioning...

https://jsr.io/@std

Re: NPM debug and chalk packages compromised

#85

Post by zahlman »

nromiun wrote: post #61

I have nothing to do with this but still I am getting second hand embarrassment. Here is an example, is-arrayish package, 73.8 MILLION downloads per week. The code? 3 lines to check if an object can be used like an array. I am sorry, but this is not due to not having a good standard library, this is just bad programming. Just pure laziness. At this point just blacklist every package starting with is-.

Meanwhile in Python: 134 million weekly downloads, seemingly slowly trending upward over time, for https://pypistats.org/packages/six which provides third-party compatibility for a version of Python that dropped support over five years ago.

Re: NPM debug and chalk packages compromised

#86

Post by tannhaeuser »

thewebguyd wrote: post #32
stathibus wrote: post #18

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

npmjs is the stdlib, or what emerged from it.

It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative also specified concrete modules such as the interfaces for node.js/express.js HTTP "middlewares" you can plug as routes and for things like auth handlers (JSGI itself was inspired by Ruby's easy REST DSL).

The reason for is-array, left-pad, etc. is that people wanted to write idiomatic code rather than use idiosyncratic JS typechecking code everywhere and use other's people packages as good citizens in a quid pro quo way.

[1]: https://wiki.commonjs.org/wiki/CommonJS

Edit: the people crying for an "authority" to just impose a stdlib fail to understand that the JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations; this concept seems lost on TypeScripters who need big daddy MS or other monopolist to sort it all out for them

Re: NPM debug and chalk packages compromised

#87

Post by Deukhoofd »

grishka wrote: post #46
dist-epoch wrote: post #33

Earlier quoted context omitted.

This is spreading everywhere, Rust, Python, ...

Not Java, thankfully! Libraries containing 1-2 trivial classes do exist, but they're an exception rather than a rule. Might be that the process of publishing to Maven Central is just convoluted enough to deter the kinds of people who would publish such libraries.

Also because Java, .NET, etc. all have very expansive standard libraries. You don't need to import most stuff, as it's already built-in.

Re: NPM debug and chalk packages compromised

#88

Post by epmatsw »

patates wrote: post #76
martypitt wrote: post #48

A super quick script to check the deps in your package-lock.json file is here[0]. [0]: https://gist.github.com/martypitt/0d50c350aa7f0fc73354754343...

aren't these already nuked and show up in the "npm audit" command?

Annoyingly, npm audit relies on github's advisory DB, which is currently incorrectly flagging all versions of these packages, not just the compromised ones.

https://github.com/github/advisory-database/issues/6098

Re: NPM debug and chalk packages compromised

#89

Post by bflesch »

junon wrote: post #45
nodesocket wrote: post #14

Earlier quoted context omitted.

What did the phishing email say that made you click and login?

That it had been more than 12 months since last updating them. Npm has done outreach before about doing security changes/enhancements in the past so this didn't really catch me. Screenshot here: https://imgur.com/a/q8s235k

Thanks for sharing, I've created an OTX entry for this: https://otx.alienvault.com/pulse/68bf031ee0452072533deee6

Re: NPM debug and chalk packages compromised

#90

Post by tracker1 »

skydhash wrote: post #58
nine_k wrote: post #30

Earlier quoted context omitted.

Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package. A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but s…

Doesn’t the bundler already do tree shaking? Optimizing via dependency listing is very wrong.

Tree shaking is less than reliable... for it to work well, all the dependencies need to be TS/ESModule imports/exports and even then may not shake out properly.

It helps, but not as much as judicious imports. I've been using Deno more for my personal projects which does have a pretty good @std library, though I do think they should keep methods that simply pass through to the Deno runtime, and should probably support working in Node and Bun as well.

Post reply on HN