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

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

691–700 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#691

Post by magicalhippo »

mbreese wrote: post #678
bilalq wrote: post #278

Earlier quoted context omitted.

You're probably already planning this, but please setup an alarm to fire off if a new package release is published that is not correlated with a CI/CD run.

Or require manual intervention to publish a new package. I'm not sure why we need to have a fully automated pipeline here to go from CI/CD to public package release. It seems like having some kind of manual user interaction to push a new version of a library would be a good thing.

I get that it can be useful sometimes. But requiring physical MFA to make a package available to the general public seems like a no-brainer to me.

Users who really want to could opt in to the bleeding edge.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#692

Post by zahlman »

bpavuk wrote: post #548
embedding-shape wrote: post #513

Earlier quoted context omitted.

> NPM is too insecure for production CLI usage. NPM was never "too insecure" and remains not "too insecure" today. This is not an issue with npm, JavaScript, NodeJS, the NodeJS foundation or anything else but the consumer of these libraries pulling in code from 3rd parties and pushing it to production environments without a single review. How this still fly today, and have been since the inception of public "easy to…

wait, I short-circuited here. wasn't the very concept of "libraries" created to *not* have to think about what exactly the code does? imagine reviewing every React update. yes, some do that (Obsidian claims to review every dependency, whether new or an update), but that's due to flaws of the ecosystem. take a look at Maven Central. it's harder to get into, but that's the price of security. you have to verify the name…

> wasn't the very concept of "libraries" created to not have to think about what exactly the code does?

If you care about security, you only have to care once, during the audit. And you can find a pretty high percentage of malware in practice without actually having a detailed understanding of the non-malicious workings of the code.

Libraries allow you to not think about what the code does at development time, which in general is much more significant than audit time. Also, importantly, they allow you not to have to design and write that part of the code.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#693

Post by sunshine-o »

I was looking at the packages affected and there are some recognizable names.

The ones that got my attentions are the @ensdomains/*, that are the legit packages and are probably in every Ethereum/EVM/blockchain related apps for the resolution of decentralized domain names.

A quick search shows those Ledger hardware wallet use those libs too [0]

So I guess they weren't just after API keys.

- [0] https://github.com/search?q=org%3ALedgerHQ%20%40ensdomain&ty...

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#694

Post by zahlman »

venturecruelty wrote: post #500
prmph wrote: post #202

There is no easy solution to these problems. The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues continue. Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection…

There absolutely is an easy solution to these problems, and Linux has been doing it forever: package maintainers. Don't treat your repository like a superfund site, and it won't fill up with garbage.

That solution is not easy, and as stated it takes work. And there is a serious problem of funding people to do that work.

And it has not yet been demonstrated at PyPI/NPM scale, either.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#695

Post by woodruffw »

mbreese wrote: post #678
bilalq wrote: post #278

Earlier quoted context omitted.

You're probably already planning this, but please setup an alarm to fire off if a new package release is published that is not correlated with a CI/CD run.

Or require manual intervention to publish a new package. I'm not sure why we need to have a fully automated pipeline here to go from CI/CD to public package release. It seems like having some kind of manual user interaction to push a new version of a library would be a good thing.

The basic issue with manual interaction is a question of authority: a pretty common problem for companies (and open source groups) is when $EARLY_EMPLOYEE/$EARLY_CONTRIBUTOR creates and owns the entire publishing process for a key package, and then leaves without performing a proper transfer of responsibility. This essentially locks the company/group out of its own work, and increases support load on community maintained indices to essentially adjudicate rightful ownership of the package name.

(There are a variety of ways to solve this, but the one I like best is automated publishing a la Trusted Publishing with environment mediated manual signoffs. GitHub and other CI/CD providers enable this.)

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#696

Post by 999900000999 »

I remember when I was young...

12 years ago NPM went down due to a very issue and getting stuff working again wasn't easy.

Someone got on GitHub and said something along the lines of "Get it together or get forked. "

I asked my manager if this was real or just a random guy talking. My manager, correctly said, it's just talk.

But it's different now. NPM is owned by Microsoft. One of the world's biggest companies should be able to sort things out.

Ohh well. Can't fix it.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#697

Post by nullbio »

dboreham wrote: post #286

Here's the underlying problem: let's imagine someone very smart. They figure out a way to solve this problem. They are not going to make any money by doing so. That's why we have this problem.

You're right, that is the underlying problem. Not only of this, but of our entire economy.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#698

Post by downrightmike »

999900000999 wrote: post #696

I remember when I was young... 12 years ago NPM went down due to a very issue and getting stuff working again wasn't easy. Someone got on GitHub and said something along the lines of "Get it together or get forked. " I asked my manager if this was real or just a random guy talking. My manager, correctly said, it's just talk. But it's different now. NPM is owned by Microsoft. One of the world's biggest companies shoul…

MSFT can't even sort Windows out, if they can't charge for it in an Enterprise license, it gets left behind. Which is why W11 is a marketing grab bag of trash.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#699

Post by giantg2 »

bodash wrote: post #252
giantg2 wrote: post #220

Earlier quoted context omitted.

Do you know of anything similar for pip?

Most of the best practices can be translated to python ecosystem. It’s not exact 1:1 mapping but change few key terms and tools, the underlying practices should be the same. Or copy that repo’s markdown into an llm and ask it to map to the pip ecosystem

Yeah, was mostly interested in the tooling.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#700

Post by philipwhiuk »

amiga386 wrote: post #172
AndroTux wrote: post #93

Earlier quoted context omitted.

Okay then, tell me a way to prevent this.

An example: Java Maven artifacts typically name the exact version of their dependencies. They rarely write "1.2.3 or any newer version in the 1.2.x series ", as is the de-facto standard in NPM dependencies. Therefore, it's up to each dependency-user to validate newer versions of dependencies before publishing a new version of their own package. Lots of manual attention needed, so a slower pace of releases. This is a…

> An example: Java Maven artifacts typically name the exact version of their dependencies. They rarely write "1.2.3 or any newer version in the 1.2.x series"

You can definitely do this.

To be honest, you just end up with the same thing via dependabot/renovate.

Post reply on HN