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

511–520 of 796 posts

Re: NPM debug and chalk packages compromised

#511

Post by typpilol »

simpaticoder wrote: post #121

I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a ma…

You can do some weird verify thing on your GitHub builds now when they publish to npm, but I've noticed you can still publish from elsewhere even with it pegged to a build?

But maybe I'm misunderstanding the feature

Re: NPM debug and chalk packages compromised

#512

Post by typpilol »

dpc_01234 wrote: post #368
HexDecOctBin wrote: post #195

Earlier quoted context omitted.

As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal. Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.

NPM dev gets hacked, packages compromised, it's detected within couple of hours. XZ got hacked, it reached development versions of major distributions undetected, right inside an _ssh_, and it only got detected due to someone luckily noticing and investigated slow ssh connections. Still some C devs will think it's a great time to come out and boast about their practices and tooling. :shrug:

Lol it's so true.. the C smugness is unmatched

Re: NPM debug and chalk packages compromised

#513

Post by bingabingabinga »

junon wrote: post #473
sneak wrote: post #472

Earlier quoted context omitted.

Can happen to anyone… who doesn’t use password manager autofill and unphishable 2FA like passkeys. Most people who get phished aren’t using password managers, or they would notice that the autofill doesn’t work because the domain is wrong. Additionally, TOTP 2FA (numeric codes) are phishable; stop using them when U2F/WebAuthn/passkeys are available. I have never been phished because I follow best practices. Most peop…

I use a password manager. I was mobile, the autofill stuff isn't installed as I don't use it often on my phone. In 15 years of maintaining OSS, I've never been pwned, phished, or anything of the sort. Thank you for your input :)

> In 15 years of maintaining OSS, I've never been pwned, phished, or anything of the sort.

Well, until now.

Re: NPM debug and chalk packages compromised

#514

Post by cataflam »

diggan wrote: post #485
cataflam wrote: post #475

Earlier quoted context omitted.

Hey, you're doing an exemplary response, transparent and fast, in what must be a very stressful situation! I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA: TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough. I don't understand how mos…

Or you know, get a password manager like the rest of us. If your password manager doesn't show the usual autofill, since the domain is different than it should, take a step back and validate everything before moving on. Have the TOTP in the same/another password manager (after considering the tradeoffs) and that can also not be entered unless the domain is right :)

I mostly agree and I do use one.

You only need read the whole thread however to see reasons why this would sometimes not be enough: sometimes the password manager does not auto-fill, so the user can think it's one of those cases, or they're on mobile and they don't have the extension there, or...

As a matter of fact, he does use one, that didn't save him, see: https://news.ycombinator.com/item?id=45175125

Re: NPM debug and chalk packages compromised

#515

Post by dabockster »

lelanthran wrote: post #376
notmyjob wrote: post #184

Earlier quoted context omitted.

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

> The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.

That wouldn't work against a really sophisticated attacker. Especially for something that's clearly being maintained for free by one overworked person in their spare time (yet again).

You'd need some kind of offline verification method as well for these widely used infrastructure libraries.

Re: NPM debug and chalk packages compromised

#516

Post by metafunctor »

jiggawatts wrote: post #489
metafunctor wrote: post #384

Earlier quoted context omitted.

Welcome to the web side. Everything’s bonkers. Hard-earned software engineering truths get tossed out, because hey, wtf, I’ll just do some stuff and yippee. Feels like everyone’s stuck at year three of software engineering, and every three years the people get swapped out.

> every three years the people get swapped out That's because they are being "replaced", in a sense! When an industry doubles every 5 years like web dev was for a long time, that by the mathematical definition means that the average developer has 5 years or less experience. Sure, the old guard eventually get to 10 or 15 years of experience, but they're simply outnumbered by an exponentially growing influx of total ne…

Good point! The web is going through its own endless September.

And so, it seems, is everything else. Perhaps, this commentary adds no value — just old man yells at cloud stuff.

Re: NPM debug and chalk packages compromised

#517

Post by rtpg »

zahlman wrote: post #85
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.

Was a bit surprised at this, but looking into the packages in a work project that require six, a _huge_ chunk of them are packages that are still explicitly supporting Python 2.7 still (usually stuff related to operations).

I believe if you pay money to certain repo maintainers like red hat you can still have a supported version of Python 2.7.

Re: NPM debug and chalk packages compromised

#518

Post by hsbauauvhabzb »

33a wrote: post #499
hsbauauvhabzb wrote: post #497

Earlier quoted context omitted.

Do I need any? Automated tools cannot prevent malicious code being injected. While they can make attempts to evaluate common heuristics and will catch low hanging malware, they are not fool proof against highly targeted attacks. Either way, the parent post is clearly ambulance chasing rather than having a productive conversation, which should really be about whether or not automatically downloading and executing huge…

When we find malware on any registry (npm, rubygems, pypi or otherwise), we immediately report it to the upstream registry and try to get it taken down. This helps reduce the blast radius from incidents like this and mitigates the damage done to the entire ecosystem. You can call it ambulance chasing, but I think this is a good thing for the whole software ecosystem if people aren't accidentally bundling cryptosteale…

So instead you prolong the problem while making money? Nice!

Re: NPM debug and chalk packages compromised

#519

Post by ants_everywhere »

junon wrote: post #473
sneak wrote: post #472

Earlier quoted context omitted.

Can happen to anyone… who doesn’t use password manager autofill and unphishable 2FA like passkeys. Most people who get phished aren’t using password managers, or they would notice that the autofill doesn’t work because the domain is wrong. Additionally, TOTP 2FA (numeric codes) are phishable; stop using them when U2F/WebAuthn/passkeys are available. I have never been phished because I follow best practices. Most peop…

I use a password manager. I was mobile, the autofill stuff isn't installed as I don't use it often on my phone. In 15 years of maintaining OSS, I've never been pwned, phished, or anything of the sort. Thank you for your input :)

sounds like you should use it on your phone then

Re: NPM debug and chalk packages compromised

#520

Post by tracker1 »

wonger_ wrote: post #447
tracker1 wrote: post #84

Earlier quoted context omitted.

Worth mentioning... https://jsr.io/@std

How is this different than npm? It looks like a bunch of third-party packages, just prefixed with std.

They are separate packages, curated by the Deno team[1]. The interfaces are pretty consistent and useful.

1. https://github.com/denoland/std

Post reply on HN