Scoket was all over this - https://socket.dev/blog/npm-author-qix-compromised-in-major-...
Nathan, do you work for Socket? I think you should at least disclose that when sharing posts here.
NPM debug and chalk packages compromised
381–390 of 796 posts
Re: NPM debug and chalk packages compromised
#382Here we are again. 12 days ago ( https://news.ycombinator.com/item?id=45039764 ) I commented how a similar compromise of Nx was totally preventable. Again, this is not the failure of a single person. This is a failure of the software industry . Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. W…
You’re right, this will only get a lot worse.
Re: NPM debug and chalk packages compromised
#383Earlier quoted context omitted.
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.
Most of these downloads, I would bet, are from CI
Re: NPM debug and chalk packages compromised
#384Earlier quoted context omitted.
Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`. In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.
Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.
Re: NPM debug and chalk packages compromised
#385Earlier quoted context omitted.
NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them
Good god. Not everything has to be about your opinion on AI.
Re: NPM debug and chalk packages compromised
#386Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…
I hate that kind of email when sent out legitimately. Google does this crap all the time pretty much conditioning their customers to click those links. And if you're really lucky it's from some subdomain they never bothered advertising as legit. Great of you to own up to it.
Re: NPM debug and chalk packages compromised
#387Earlier quoted context omitted.
Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts. [1] https://www.debian.org/doc/manuals/securing-debian-manual/de...
In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense. So if we're discussin…
Re: NPM debug and chalk packages compromised
#388Earlier quoted context omitted.
I don't understand. The link could've come from anywhere (for example from a HN comment). How does just clicking on it give your package credentials to someone else? Is NPM also at fault here? I'd naively think that this shouldn't be possible. For example, GitHub asks for 2FA when I change certain repo settings (or when deleting a repo etc.) even when I'm logged in. Maybe NPM needs to do the same?
OP entered their credentials and TOTP code, which the attacker proxied to the real npmjs.com FWIW npmjs does support FIDO2 including hard tokens like Yubikey. They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages. iirc GitHub does force re-auth when you request an access token.
I'm surprised by this. Yeah, GitHub definitely forces you to re-auth when accessing certain settings.
Re: NPM debug and chalk packages compromised
#389Earlier quoted context omitted.
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.
But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import , that you can track and version and pay attention to. Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar. Why instead do people in the javascript ecosystem insist on se…
Re: NPM debug and chalk packages compromised
#390One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one. This is a brilliant…
We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast). That way it's much harder to make one hash look like another.