1. Buy expired NPM maintainer email domains.
2. Re-create maintainer emails
3. Take over packages
4. Submit legitimate security patches that include package.json version bumps to malicious dependency you pushed
5. Enjoy world domination.
I just noticed "foreach" on npm is controlled by a single maintainer.
I also noticed they let their personal email domain expire, so I bought it before someone else did.
I now control "foreach" on NPM, and the 36826 projects that depend on it.
@[email protected] foreach sounds like a package that you shouldnt need with Array.prototype.forEach 
@Johann150 yes, that's true. It made it into ECMAScript 5.1
Now if you've for _some_ weird reason a system that requries some _older_ build target you get a polyfill.
That was provided by packages like this and should be helluvEOL nowadays. There are better suited and highly automated polyfills.
Anyway, the issue is very real. This happened before and will happen again.
It's also the very same for most language depending package managers out there and this is why version pinning is a thing.
@bekopharm
So it could happen to PyPI (Python), RubyGems (Ruby), Crates (Rust), … too :-(
@Johann150
With npn it happens more often because of the higher visibility, of the culture of tiny libraries that multiplies the attack surface by a few orders of magnitude and other social factors.
One where everybody can upload, and I as a moderately competent software person can go to discover new things, review them (both as code and as maintainership situation), decide whether or not I want to trust them.
And another where I as a tired person who needs the software|library *now* can go and get things (and trust automatic updates) knowing that somebody has already given them at least a bit of review, that there are automatic systems in place to keep checking that it keeps working, that there are procedure in place to substitute the people involved in this review if they disappear, if there are security patches I will get them applied without having to upgrade to a completely new version at a random time and basically all the things that I would have to do personally to safely use in production code taken directly from the first layer.
@valhalla @clacke @federico3 @bekopharm @Sandra @lrvick @technicallypossible @ruffni @Johann150 @RyunoKi
The second layer is called "distros" :P
@valhalla @clacke @federico3 @bekopharm @Sandra @lrvick @technicallypossible @ruffni @Johann150 @RyunoKi also, since with the first layer you have to re-audit with every update, you may as well vendor that dependency (as in, put a copy of a specific version in your repo), so arguably github could be enough as the first layer
¹ because that's what I use and what runs on production. substitute with fedora, arch, whatever else may apply.
@valhalla
Hard to do with multiple projects on the same machine.
Nor using Docker or VMs.
(Anybody want to stop getting notified?)
@clacke @federico3 @bekopharm @wolf480pl @Sandra @lrvick @technicallypossible @ruffni @Johann150
@federico3
That sounds like something I need to research more.
So far I only used chroot for repairing broken installations.
@valhalla
@RyunoKi
There's a series of articles starting from:
https://www.enricozini.org/blog/2021/debian/gitlab-runners-with-nspawn/
Most of the time you just need an ephemeral run akin to running chroot.
Some kind of distributed directory would be even better, but I'm not the person who will write one any time soon :D