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.

@wolf480pl Preventing other people from using it is enough. That and using it as a chance to educate pepole on why thy can't trust NPM.

@lrvick if only all people seeking world domination were like you

@technicallypossible @wolf480pl I don't recommend trusting me... or any single individual, with this kind of power.

If someone asks me nicely with a rubber hose, I will be obliged to hand over access.

There is a reason the name of my company is "Distrust"

Distrust should lead to Distributed Trust.

Demand multisig code reviews, and multisig reproducibly built releases for anything that matters.

@lrvick Trust Issues as a Service (TIaaS) is like Zero Trust, but better 😉

@lrvick @technicallypossible @wolf480pl Random neighbor standing out front watering their lawn: "Hey Lance, can you hand me over access?"

You, noticing the hose is made of vinyl or something instead of rubber: "Haha no."

@lrvick @wolf480pl

Maybe you should just replace the package with a link to MDN's entry on the regular foreach 🤷‍♀️

@lrvick @wolf480pl or any package manager that allows password resets via email

@lrvick So basically there are no signature checks on packages on npm?

Why am I not surprised?

@lrvick@mastodon.social foreach sounds like a package that you shouldnt need with Array.prototype.forEach :blobfoxthonking:

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

So it could happen to PyPI (Python), RubyGems (Ruby), Crates (Rust), … too :-(

@RyunoKi …and browser extensions and game mods. Heck, whatever allows to regain access to an account via mail basically.

No 2FA on your Google Dev account? Too bad 🙃

@RyunoKi Google boo whatever. Try releasing a Chrome extension without :P

(Or an Android app).


Why would I want to write for Chrome?
That doesn't help Firefox at all.

@bekopharm @Johann150 @RyunoKi Attacks on PyPI (the one I know best) and the others based on the fact that anybody can upload a new package have already happened and will keep happening.

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.
@clacke @federico3 @bekopharm @wolf480pl @Sandra @lrvick @technicallypossible @ruffni @Johann150 @RyunoKi Personally I very much prefer to live in a world where there are two layers in the distribution of software (libraries).

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

@clacke @federico3 @bekopharm @wolf480pl @Sandra @lrvick @technicallypossible @ruffni @Johann150 @RyunoKi Honestly having a central point for all things python which is just little more than a directory feels nicer than the alternative of having to go through github, condemning to oblivion everybody who wants to host elsewhere (including self-host).

Some kind of distributed directory would be even better, but I'm not the person who will write one any time soon :D
@clacke @federico3 @bekopharm @wolf480pl @Sandra @lrvick @technicallypossible @ruffni @Johann150 @RyunoKi Also, my personal choice rather than vendoring would be to package and upload for debian¹: 90+% of the work has already been done, I might as well do the last bit and make my work useful for everybody else.

¹ because that's what I use and what runs on production. substitute with fedora, arch, whatever else may apply.

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

@RyunoKi @valhalla
Each project can be installed with the required OS dependencies. In case you need to test something against an older Debian release you can just use a simple chroot or systemd-nspawn as a container. Less messy and more secure than docker.

That sounds like something I need to research more.

So far I only used chroot for repairing broken installations.

There's a series of articles starting from:
Most of the time you just need an ephemeral run akin to running chroot.

@yes @Johann150 @RyunoKi sorry, failed to parse that but yes, that's a very common thing in npm too due to it's popularity.

That's a different attack vector.

The above is turning a benevolent package into a malicious one while there is seemingly no change in authorship (same email address)

@root @lrvick

Hmm, I can't not read that in Norwegian, it basically say: "Masturbation moment" p

@sotolf @lrvick lol yeah

the context is this tweet: https://twitter.com/6thgrade4ever/status/1433519577892327424

"the most consequential figures in the tech world are half guys like steve jobs and bill gates and half some guy named ronald who maintains a unix tool called 'runk' which stands for Ronald's Universal Number Kounter and handles all math for every machine on earth"

@lrvick Do any Fossil Fuel companies use ForEach or any of its dependent packages, I wonder?

@seachaint @lrvick They're probably still using an all-Java back-end. They sank so much money into instrumentation and monitoring of the JVM they're not going to change anytime soon.

Also, don't tell them you know anything more modern. They will probably not hire you.

@drwho @lrvick I'm not sure whether there's a crossed wire somewhere, but I would never work for a fossil fuel company no matter what their back-end was? :)

I was not-so-subtly suggesting, rather, that having the power to specifically exclude certain classes of genocidal business from using a large swathe of NPM stuff for their websites or back-ends would be.. tempting.

@lrvick It seems that the (in)famous is-equal has a developer dependency to it 😁

@lrvick I wonder if anyone ever tried monetization...ya know, show a popup ad everytime someone enters a foreach section.

Remeber: with great power comes great responsibility.

@lrvick i think you should do something terrible with this

@lrvick congrats

also, explored it & very quickly went from "why does js even need a foreach package" to "oh, it's only 21 lines" :)

@patterfloof @lrvick I'm tertibly amused when I see node devs adding dependencies for stuff like this, meanwhile my "fun" project has a custom json parser/emitter with entity inheritance, a reimplementation of gettext, a curses-to-windows-terminal API adapter, and internal implementations of several c++ std types.

@kevingranade @lrvick there's so many times I've written my own functions in PHP because "it's a small understandable problem, not worthy of a library" then later found I could have picked up someone else's code & spent ages massaging it to work

@lrvick if the email wasn't public it'll help a bit. I tend to register to various platforms with my private email address and share public one with everybody else unfortunately many platforms leak your email somewhere.

@lrvick make it print a rickroll to console everytime a function from the package is called

Sign in to participate in the conversation

The original server operated by the Mastodon gGmbH non-profit