The issue (as summed up in the title) is that:
- a malicious actor obtained ownership of a module distributed on a community repo
Uh, oh. Well, this is a known anti-pattern.
- the module is quite popular (millions of installs per week)
As npm goes… (and oh, it is probably worse, since a sizeable
part of those “millions” is… continuous integration systems,
which are ultimately deploying the thing semi-automatically).
- the version on the repo included malware vs. the commit was apparently not appearing on the origin (here, GitHub).
Again, uh-oh.
This raises several questions:
- how communities should govern the management of repos and packages/modules in their repos
(e.g. Debian repos vs AUR vs NPM)
In the case of Debian I’m somewhat confident, because I trust its
culture. But it does pay a price for that – it’s perceived as
“slow”, and everyone and her dog is clamoring for setups like
Flatpak, where bleeding edge flows directly into end-user system.
Some software packages (esp. those which have received more power
than is healthy for them – think Web browsers) include an auto-update
system which bypasses the distribution’s.
Personally I sleep better by having a QA instance between the software
maker and myself (unless it is one of those rare packages I’m especially
interested in, and where I take the QA responsibility myself, but I
can afford that for a small handful of packages, at most).
- how maintainers should handle situations where they don’t want to continue maintaining something (in my opinion, transferring ownership to a random developer does not seem like a great idea for a module with millions of weekly installs. But it seems that’s what happened here.)
There are several levels of maintainers: the software maker’s
maintainers, the distro package maintainers, etc.
Of course, we are seeing the same “rationalization pressures” so
dear to us in this modern consumer economy. And Free software (more
so when confused with Open Source) is “free”, meaning that you can
“start” your “up” without contributing – leading to an appalling
state of infrastructure.
Look up heartbleed and the OpenSSL libraries to see a sad story which
predates your npm story by some two years or so. It turned out that
the whole of OpenSSL, on which relied the Web’s security (banking and
all that) was kept running by (I believe) four persons, all of them
doing it in their free time.
The “solution” at that time was to create the Core Infrastructure
Initiative [1] where vendors could throw in some cash to keep
the lights on for important projects.
This is all well and good, but imagine diluting that over the (how
many? 450k?) packages in the npm repository. Hmmm.
My take on this? We are forgetting how to program and are compelled
to go shopping more and more often. But I’m an old curmudgeon myself.
- how developers and users of other packages should handle dependencies on other people’s packages
Typically this is based on trust, and trust is based on
culture. A difficult thing in itself. I don’t thing there’s
a technical solution to that. It is an eminently social
problem.
- how do we ensure audits, monitoring, etc.
How do we ensure that those profitting from free (software, data, etc.)
give back something? Take Amazon’s gift to the Wikimedia foundation.
They donated $1M, which sounds like a lot of money, until you learn
that Alexa wouldn’t have been the success it was without Wikipedia’s
huge and well-structured data basis.
We’re just seeing the same anti-pattern of strip-mining without regard
to externalities (environment, social repercussions, etc.) which we
know so well and love and which is the hallmark of extractive capitalism.
Surprised? I’m not.
- how do we mitigate and remediate situations like this when they happen.
Perhaps by pursuing other ways of doing things. Cooperatives. Alternative
economy. Stay out of the way from Big Platforms (and their anti-patterns:
that’s why I’m so sceptical of this very Discourse thingy, btw.)
What else? Thoughts?
I was very excited by the last Bits und Bäume in Berlin: I think we
Free Software people should look around us for close relatives in
other fields.
Cheers
[1] https://www.coreinfrastructure.org/
– tomás