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

661–670 of 796 posts

Re: NPM debug and chalk packages compromised

#661

Post by egorfine »

gslepak wrote: post #543
egorfine wrote: post #452

Earlier quoted context omitted.

> Don't update dependencies unless necessary And get yourself drowning in insurmountable technical debt in about two months. JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.

> 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.

Re: NPM debug and chalk packages compromised

#662

Post by palmfacehn »

crabmusket wrote: post #595
palmfacehn wrote: post #589

Earlier quoted context omitted.

A batteries included standard lib included with the runtime is one approach. Yes, you would know upfront the version which the browser implements. From there you could dynamically load a polyfill or prompt the user to upgrade. Alternatively, because there are now (often ridiculous) build systems and compilation steps, we might expect similar behavior to other compiled binaries. Instead we get the worst of both worlds…

> A purely compiled WASM approach I would love to see if a browser could like... "disaggregate" itself into WASM modules. E.g. why couldn't new JS standards be implemented in WASM and hot loaded into the browser itself from a trusted distributor when necessary? Missing CSS Level 5 selectors? Browser goes and grabs the reference implementation from the W3C. Low-level implementations could replace these for the browser…

Yes, that would be a compelling change. Like a language agnostic HotJava platform. We're overdue for a more coherent approach, from the bottom up.

Re: NPM debug and chalk packages compromised

#663

Post by Intermernet »

marcus_holmes wrote: post #549
dabockster wrote: post #500

Earlier quoted context omitted.

> Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date. npm sold it really hard that you could rely on them and not have to vendor dependencies yourself. If I suggested that a decade ago in Seattle, I would have gotten booed out of the room.

I have repeatedly been met with derision when pointing out what a gaping security nightmare the whole Open Source system is, especially npm and its ilk. Yet here we are. And this is going to get massively worse, not better.

Nothing specific to open source is to blame in this instance. The author got phished. Open source software often has better code vetting and verification than closed source software. npm, however, does not.

Re: NPM debug and chalk packages compromised

#665

Post by DecoySalamander »

lpribis wrote: post #474
egorfine wrote: post #452

Earlier quoted context omitted.

> Don't update dependencies unless necessary And get yourself drowning in insurmountable technical debt in about two months. JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.

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 really isn't, and I've never seen anyone do that. In every project I've worked on in the past decade, dependencies were only occasionally bumped in the context of some maintenance task or migration.

Re: NPM debug and chalk packages compromised

#667

Post by yread »

jiggawatts wrote: post #491
parliament32 wrote: post #267

Earlier quoted context omitted.

The NPM team has repeatedly commented that it's "too hard", effectively, and would discourage new developers from publishing packages. See: https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://news.ycombinator.com/item?id=38645969 https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...

> 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: ESC/C1, optional intermediates, optional params (supports ; and :) then final byte
 const csi = '[\\u001B\\u009B][[\\]()#;?]*(?:\\d{1,4}(?:[;:]\\d{0,4})*)?[\\dA-PR-TZcf-nq-uy=>

Re: NPM debug and chalk packages compromised

#668

Post by yread »

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.

   content-security-policy: default-src 'self';
(and not sending crypto transactions): No need to worry about CVEs in js

Re: NPM debug and chalk packages compromised

#669

Post by solatic »

a022311 wrote: post #169

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

Hell no. CI needs to be a clean environment, without any human hands in the loop.

Publishing to public registries should require a chain of signatures. CI should refuse to build artifacts from unsigned commits, and CI should attach an additional signature attesting that it built the final artifact based on the original signed commit. Public registries should confirm both the signature on the commit and the signature on the artifact before publishing. Developers without mature CI can optionally use the same signature for both the source commit and the artifact (i.e. to attest to artifacts they built on their laptop). Changes to signatures should require at least 24 hours to apply and longer (72 hours) for highly popular foundation packages.

Re: NPM debug and chalk packages compromised

#670

Post by mnahkies »

b112 wrote: post #641
SchemaLoad wrote: post #568

Earlier quoted context omitted.

2FA is a huge benefit over plain passwords. But it wasn't enough here. The package dev had 2FA and it did not help since they got tricked in to logging in to a phishing page which proxied the 2FA code to the real login page.

Yet the parent said for each upload prior to publish. This attack would have 100% been thwarted, when a load of emails appeared saying "publish package you just uploaded?". (if you read the dev's account of this, you'll see this would have worked)

Another advantage of this would be for CI/CD - MFA can be a pain for this.

If I could have a publish token / oidc Auth in CI that required an additional manual approve in the web UI before it was actually published I could imagine this working well.

It would help reduce risk from CI system breaches as well.

There are already "package published" notification emails, it's just at that point it's too late.

Post reply on HN