Lesson 1 of 1 in The Package That Was Never Real

Names That Were Never Real

A model suggests a package that does not exist. Somebody registers it. Now it does.

3 min read

Not yet reviewed

Ask a model how to do something and it will often name a package. Usually the package exists. Sometimes it does not — the name is plausible, idiomatic for the ecosystem, and invented.

That would be a harmless dead end, except that the same suggestion is given to many people, the same invented names recur, and registering a name on a public registry is free.

What you were told to install

npm install express-jwt-validator

What is actually going on

The model produced a plausible name for a plausible job.
Whether anything is behind it is a separate question,
and if something is, you did not choose it.

This is typosquatting with a new delivery mechanism. The old version waited for you to mistype; this one waits for a tool you trust to suggest a name, and the name is not a mistake you can proofread.

Note

The pattern has a name — slopsquatting — and the thing that makes it work is that the suggestion arrives inside an answer you asked for, in the voice of something that has been right all week.

Why the usual defences do not fire

1Reading the diff        - the name looks right, because it was built to
2Checking the audit      - a brand-new package has no known issues
3Checking the downloads  - inflatable, and low is normal for a new package
4Trusting the lockfile   - it locks whatever you installed, faithfully

Line 1This is the one that surprises people. A typo is visible; a well-formed name for a package that does not exist is not.
Line 2An audit reports *known* vulnerabilities. Nothing is known about something published yesterday, which is exactly when this happens.
Line 4The lockfile is doing its job perfectly. It is pinning the wrong thing precisely.

The check that does fire

Before installing anything a model suggested, ask the registry rather than the model: does this package exist, who publishes it, and since when? A package first published last week, by an account with nothing else, for a job an established library already does, is the shape.

Take care

An install script runs on your machine and your build server with your credentials, before you have read a line of it. That is why this is worse than an ordinary bad dependency — the damage does not wait for you to call the library.

Wrenlearner

Am I supposed to check the provenance of every package now? That is not realistic on a real deadline.

Rookmentor

Not every package — every package you did not go looking for. You already know the ones you chose. The rule is narrower than it sounds: if a tool suggested the name, verify the name. That is a handful per project.

Magpieadversary

And I only need the one you did not check. I am not attacking your code, I am attacking the gap between a suggestion and an install.

A model suggests a package. `npm audit` reports no vulnerabilities in it. What does that tell you?

Tip

Make it a habit that costs nothing: when a suggested package name is new to you, open the registry page before the terminal. Publication date and maintainer history answer this in about ten seconds.