Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

701–710 of 796 posts

Re: NPM debug and chalk packages compromised

#701

Earlier quoted context omitted.

I would agree if this were one of those `curl | sh` scenarios, but don't we consider things like `brew` to be sufficiently low-risk, akin to `apt`, `dnf`, and the like?

Anyone can upload an NPM package without much review. For Homebrew, you at least have to submit a pull request.

https://docs.brew.sh/Acceptable-Casks#apps-that-bundle-malwa...

> Unfortunately, in the world of software there are bad actors that bundle malware with their apps. Even so, Homebrew Cask has long decided it will not be an active gatekeeper (macOS already has one) and users are expected to know about the software they are installing. This means we will not always remove casks that link to these apps, in part because there is no clear line between useful app, potentially unwanted program, and the different shades of malware—what is useful to one user may be seen as malicious by another.

---

So there might be pull requests, but Brew's official stance is that they do not actively moderate casks for malware. I guess there's something built into the MacOS packaging step that help mitigate the risk, but I don't know much about it outside playing w/ app development in XCode.

Re: NPM debug and chalk packages compromised

#702

Earlier quoted context omitted.

For a package with thousands of downloads a week, does the publishing pace need to be so fast? New version could be uploaded to NPM, then perhaps a notification email to the maintainer saying it will go live on XX date and click here to cancel?

A standard release process for Linux distro packages is 1) submitting a new revision, 2) having it approved by a repository maintainer, 3) it cooks a while in unstable, 4) then in testing, and finally 5) is released as stable. So there's an approval process, a testing phase, and finally a release. And since it's impossible for people to upload a brand new package into a package repository without this process, typosq…

And for any Arch users reading this, AUR is the wild west too.

Re: NPM debug and chalk packages compromised

#703

Earlier quoted context omitted.

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.

> That wouldn't work against a really sophisticated attacker. Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply. > You'd need some kind of offline verification method as well for these widely used infrastructure libraries. I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be…

> X509 certificate

It should be a PGP or SSH key, absolutely not an X509 certificate (unless you allow self signed).

Personal identity keys should be fully autonomous and not contingent on the formal recognition of any external authority.

Re: NPM debug and chalk packages compromised

#706
post #517
post #85

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

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.

> a _huge_ chunk of them are packages that are still explicitly supporting Python 2.7 still

Do you know if they also support 3.x?

Do you know if they're available on PyPI?

> (usually stuff related to operations).

What kind of "operations" do you mean?

Re: NPM debug and chalk packages compromised

#707
post #39

looks like it won't affect you if you just downloaded the packages locally. the actual code only runs in a browser context - it replaces all crypto addresses in many places with the attacker's. a list of the attacker's wallet addresses: https://gist.github.com/sindresorhus/2b7466b1ec36376b8742dc7...

Etherscan has tagged these addresses already. As of this check, none of the other block explorers have. Etherscan - yes - https://etherscan.io/address/0x4Cb4c0E7057829c378Eb7A9b174B0...

Mempool.space - no Blockchair - no Tronscan - no Blockcypher.com - no Blockread.io - no

Re: NPM debug and chalk packages compromised

#708
post #671

Earlier quoted context omitted.

I feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished. I have to manually select the site to fill fairly often, especially inside apps where the password manager doesn't seem to match the app to the website password. Passkeys seem like the best solution here where you physically can not fall for a phishing attack.

> I feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished I dunno, it mostly seems to not work when companies change their field names/IDs, or just 3rd party authentication, then you need to manually add domains. Otherwise my password manager (1Password) works everywhere where I have an account, except my previous bank which was stuck in the 90s and disall…

I'm glad you've had such good experience with autofill consistently working for you. My experience has been closer to that of the sibling comments: 60/40 so I often just give up and copy-paste. I actually did try jettisoning 1Password for Proton Pass but that was even worse, so I went back

> without any migration strategy or import/export support

Since you're already a 1Password user, I wanted to draw your attention to the "Show debugging tools" in the "Settings > Advanced" section. From that point, you can say "Copy Item JSON" and it will give you the details you would want for rescuing the Passkey. Importing it into something else is its own journey that I can't help with

  {
    "overview": {
      "passkey": {
        "credentialId": "...",
        "rpId": "example.com",
        "userHandle": "..."
      },
    ...
    "details": {
      "passkey": {
        "type": "webauthn",
        "createdAt": 175.......,
        "privateKey": "eyJ...",
        "userHandle": "..."
      }
I would guess their "op" CLI would allow similar, but I don't have the magic incantation to offer, whereas that Copy JSON is painless

Re: NPM debug and chalk packages compromised

#709

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.

No kidding. New developers need to learn the important skill of doing something correctly, not just “ship fast; break things”

Re: NPM debug and chalk packages compromised

#710

Earlier quoted context omitted.

You rely on LLMs riddled with hallucinations for malware detection?

He literally said "Flagged packages are escalated to a human review team." in the second sentence. Wtf is the problem here?

What about packages that are not "flagged"? There could be hallucinations when deciding to (or not) "flag packages".
Post reply on HN