Developer account got hijacked through phishing. @junon acknowledged this readily and is trying to get it sorted. Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight.

So let me raise a different concern. This looks like an exploit for web browsers, where an average user (and most above average users) have no clue as to what's running underneath. And cryptocurrency and web3 aren't the only sensitive information that browsers handle. Meaning that similar exploits could arise targeting any of those. With millions of developers, someone is bound to repeat the same mistake sooner or later. And with some packages downloaded thousands of times per day, some CI/CD system will pull it in and publish it in production. This is a bigger problem than just a developer's oversight.

- How do the end user protect themselves at this point? Especially the average user?

- How do you prevent supply chain compromises like this?

- What about other language registries?

- What about other platforms? (binaries, JVM, etc?)

This isn't a rhetorical question. Please discuss the solutions that you use or are aware of.

> Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight.

Unless this is a situation that could've been easily avoided with a password manager since the link was from a website not in your manager's database, so can't happen to anyone following security basics, and the point of discussing the oversight instead of just giving up is to increase the share of people who follow the basics?

One thing I've been thinking of is to restrict global access to packages. Something like ansi-styles doesn't need access to the crypto global, or to the DOM, or make web requests, etc. So if you can sandbox individual libraries, you can decrease the attack surface a lot.

You could imagine that a compromised pad-left package could read the contents of all password inputs on the page and send it to an attacker server, but if you don't let that package access the document, or send web requests, you can avoid this compromise.

> How do the end user protect themselves at this point? Especially the average user?

Don't use unregulated financial products. The likelihood of a bank being hit by this isn't zero - but in most parts of the world they would be liable and the end user would be refunded.

> How do you prevent supply chain compromises like this?

Strictly audit your code.

There's no magic answer here. Oh, I'm sure you can throw an LLM at the problem and hope that the number of false positives and false negatives don't drown you. But it comes down to having an engineering culture which moves slowly and doesn't break things.

> How do you prevent supply chain compromises like this? Take a look at https://github.com/AikidoSec/safe-chain and https://intel.aikido.dev/?tab=malware! Disclaimer: I work at Aikido Security :)

Packj [1] detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting).

1. https://github.com/ossillate-inc/packj

> - How do the end user protect themselves at this point? Especially the average user?

- Install as little software as possible, use websites if possible.

- Keep important stuff (especially cryptocurrency) on a separate device.

- If you are working on a project that pulls 100s of dependencies from a package registry, put that project on a VM or container.