You asked for a way to parse
an awkward date format,
and the answer was tidy.
Install this package.
Import this function.
Three lines.
The name was perfect.
It sounded exactly like
the thing you would expect
somebody to have written.
That is the problem.
A model producing a dependency name
is doing what it does
with every other word.
It predicts what a name
in that position
would plausibly be.
Most of the time
the plausible name is real,
because real names are plausible.
Some of the time
it is only plausible.
And a name that a model
suggests to one person
it will suggest to thousands,
because it is the same model
answering the same kind of question.
So the invented name repeats.
Which means somebody
can collect them,
register the popular ones
on a public registry,
and wait.
No break-in.
No stolen password.
Just a package
that did not exist
until the model kept naming it,
with an install script
that runs on your laptop,
with your tokens in the environment,
the moment you type the command
the answer gave you.
Reading the code will not save you.
You were looking at three lines
of sensible code.
The danger was never in them.
It was in the one line
that fetched somebody else's.
So put the check where the risk is.
Before a new name goes in,
look it up yourself.
Not through the assistant.
On the registry.
How old is it.
Who publishes it.
How many people depend on it.
Does it have a repository,
and does that repository
look like somebody's work
or like a costume.
A week old,
one version,
one maintainer,
and a name that sounds
like it has always existed,
is the exact shape
of this trap.
Then make it structural.
Install from a lockfile in the pipeline.
Put new dependencies
through review as their own change,
where the only question
is whether this thing
should be allowed in at all.
The model can suggest.
The registry is where
you find out
what you are about to run.
– Serguey Asael Shinder
Top comments (0)