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

741–750 of 796 posts

Re: NPM debug and chalk packages compromised

#741

Post by graemep »

cataflam wrote: post #475
junon wrote: post #9

Hi, 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…

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…

> NEVER EVER login from an email link. EVER

Login using one off email links (instead of username + password) is increasingly common which means its the only option.

Re: NPM debug and chalk packages compromised

#742

Post by johnisgood »

sneak wrote: post #646
junon wrote: post #473

Earlier quoted context omitted.

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 :)

I never copy and paste passwords. Any time you find yourself wanting to do that, alarm bells should be ringing. Password managers can’t help you if you don’t use them properly. Spotify steals (and presumably uploads) your clipboard, as well as other apps. Autofill is your primary defense against phishing, as you (and hopefully some others) learned this week.

Do not give them permission to your clipboard. It is possible today. I copy and paste passwords and I clear the clipboard afterwards, and I do not use junk like Spotify, and were I to use Spotify, it would be through the browser, not the application. Were it the application, it would be firejailed to oblivion.

It is possible to restrict clipboard access when running applications inside Firejail, i.e. Firejail allows you to restrict access to X11 and Wayland sockets, which prevents the sandboxed application from reading or writing to the system clipboard. See: "--x11=none", "--private=...", "--private-tmp", and so forth. You can run a GUI app with isolated clipboard via "firejail --x11=xvfb app".

For Wayland, you should block access to the Wayland socket by adding "--blacklist=/run/user/*/wayland-*".

I do not use autofill on desktop at all. I use it on Android, however.

Re: NPM debug and chalk packages compromised

#743

Post by hirako2000 »

graemep wrote: post #741
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…

> NEVER EVER login from an email link. EVER Login using one off email links (instead of username + password) is increasingly common which means its the only option.

At least you've requested that email, to be able to login. The timing chance for a phishing mail to come here and there is insignificant. OP is referring to communications that are one way street, the (pseudo) organisation to you.

Re: NPM debug and chalk packages compromised

#744

Post by thunderfork »

josefbud wrote: post #372
rimunroe wrote: post #352

Earlier quoted context omitted.

npm ci should be much faster in CI as it can install the exact dependency versions directly from the lockfile rather than having to go through the whole dependency resolution algorithm. In CI environments you don't have to wait to delete a potentially large pre-existing node_modules directory since you should be starting fresh each time anyway.

I've seen pipelines that cache node modules between runs to save time, but yeah if they're not doing that then you're totally right.

[dead]

Re: NPM debug and chalk packages compromised

#745

Post by thunderfork »

jffry wrote: post #597
Already__Taken wrote: post #479

Earlier quoted context omitted.

We didn't get locking until npm v5 (some memory and googling, could be wrong.) And it took a long time to do everything you'd think you want. Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?

> Anyway didn't this replace versions, so locking won't have helped either? The lockfile includes a hash of the tarball, doesn't it?

[dead]

Re: NPM debug and chalk packages compromised

#746

Post by Already__Taken »

jffry wrote: post #597
Already__Taken wrote: post #479

Earlier quoted context omitted.

We didn't get locking until npm v5 (some memory and googling, could be wrong.) And it took a long time to do everything you'd think you want. Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?

> Anyway didn't this replace versions, so locking won't have helped either? The lockfile includes a hash of the tarball, doesn't it?

It does, the answer to my question was no.

Re: NPM debug and chalk packages compromised

#747

Post by 1718627440 »

HexDecOctBin wrote: post #195
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…

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.

This isn't part of the current discussion, but what is the appeal of single-header libraries?

Most times they actually are a normal .c/.h combo, but the implementation was moved to the "header" file and is simply only exposed by defining some macro. When it is actually a like a single file, that can be included multiple times, there is still code in it, so it is only a header file in name.

What is the big deal in actually using the convention like it is intended to and name the file containing the code *.c ? If is intended to only be included this can be still done.

> avoiding the C standard library are regressive and obsolete

I don't understand this as well, since the one half of libc are syscall wrappers and the other half are primitives which the compiler will use to replace your hand-rolled versions anyway. But this is not harming anyone and picking a good "core" library will probably make your code more consistent and readable.

Re: NPM debug and chalk packages compromised

#748

Post by 1718627440 »

yread wrote: post #667
jiggawatts wrote: post #491

Earlier quoted context omitted.

> discourage new developers from publishing packages Good.

It's not like these packages are super sophisticated million LOCs masterpieces. ansi-regex is literally just this: export default function ansiRegex({onlyFirst = false} = {}) { // Valid string terminator sequences are BEL, ESC\, and 0x9c const ST = '(?:\\u0007|\\u001B\\u005C|\\u009C)'; // OSC sequences only: ESC ] ... ST (non-greedy until the first ST) const osc = `(?:\\u001B\\][\\s\\S]*?${ST})`; // CSI and related:…

   ... | wc -c
   592
592 bytes of code including comments and whitespace versus which amount of overhead in package description, tarball caches, etc...?

Re: NPM debug and chalk packages compromised

#749

Post by 1718627440 »

egorfine wrote: post #482
lpribis wrote: post #474

Earlier quoted context omitted.

Updating packages daily (!) is insane to me as someone from the other end of the programming spectrum (embedded C). Is this really the recommended practice?

It is insane to me as a C programmer as well. It is something I got used to as a frontend js developer. It so recommend to stay on top of the dependencies and for different stacks this means different update schedule. For some, daily is indeed a good choice.

Even if there is a new version every day, not every release is born equal. Wouldn't updating while developing to "stay on top of dependencies" only be necessary on a major version? Surely there is not a major version per day. I mean otherwise you would use a library, that constantly imposes work on you and it would probably make more sense to write the library yourself. Minor versions and bugfixes can be incorporated when you do your release.

Re: NPM debug and chalk packages compromised

#750

Post by 1718627440 »

egorfine wrote: post #661
gslepak wrote: post #543

Earlier quoted context omitted.

> daily Somehow we've survived without updating dependencies for probably at least a year.

Then you probably have over a dozen CVEs in your code. Now, this is a different question whether they are exploitable and how much it is a risk. Other than that you now probably have an insurmountable technical debt and upgrading the dependencies is a project of itself. All the above applies to JavaScript world, of course. It's much different for the rest.

If a library introduces CVEs per day, it's probably not so good to begin with.
Post reply on HN