Hi,
On 2020-07-02 02:41, Aron Manning wrote:
Recently, I haven't seen the security question of
npm being discussed on
https://phabricator.wikimedia.org/T199004
and thought that question was not on topic. If that's not the case: is
there another discussion I'm not aware of?
There's been some work around protecting developers from npm packages,
especially <https://gerrit.wikimedia.org/g/fresh/> but I don't believe
there are any active public discussions.
The issue of package security has been answered by the
Node community
multiple times in different forms through the years.
Were these solutions evaluated? These generally avoid unvetted code by
hosting a *private node package repository* in some form,
typically in a git repository, where only *vetted versions* of
packages are
checked in.
In theory this addresses the problems, but I think the biggest problem
is just the volume and quality of code that needs reviewing.
Take <https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/605082/>
for example. It bumps 3 packages: stylelint-config-wikimedia (owned by
us), webpack (minor version bump), and markdown-to-jsx (patch bump). The
latter two are security issues (whether they're actually exploitable in
our context is another discussion).
Here's what the actual diff looks like:
<https://libup-diff.wmflabs.org/change/605082>.
There's at least a thousand lines changed, not including the
minified/compiled code that's impossible to review. And that doesn't
even show the npm packages that download compiled binaries on installation.
(Feel free to throw other patches at the libup-diff tool, but it's alpha
quality still, I hadn't fixed it up enough yet to announce it.)
I don't believe it's possible to review that much code on a regular
basis, reacting to the speed at which many npm packages move. We could
stop upgrading all the time, but that would effectively be forking and
IMO put us in a worse position.
I also note that it's impossible to review just the git changelog of a
package, because the npm maintainer can upload any arbitrary tarball of
code to npm, whether or not it matches the git repo. (This isn't
exclusive to npm, pypi, crates.io suffer from this problem too.
composer/packagist doesn't though.)
These include the complete dependency trees, the
package hashes and the
full source code of packages, therefore provide more complete security
than
libraryupgrader2, which - in my understanding - only
controls our
top-level
dependencies.
npm dependency trees should be fully locked via package-lock.json. libup
currently only upgrades top-level dependencies, but it also runs `npm
audit fix` in response to npm security advisories (see the current
listing: <https://libraryupgrader2.wmflabs.org/vulns/npm>).
But honestly I consider libup's "npm audit fix" mode just damage control
at this point. If we can't trust the code we're running, then we're more
likely to protect ourselves by fixing the security issues we do know about.
In short, if you've been running npm install/test/etc. on your machine,
I would consider any ssh/GPG/etc. keys that it could've accessed
compromised. Krinkle goes into this much better in his blog post:
<https://timotijhof.net/posts/2019/protect-yourself-from-npm/>.
Without completeness I'd mention 2 recent
solutions:
<snip>
How do these alternative package managers address the quantity of npm
packages installed that need review?
2. I've been using these PMs and made the
necessary additions to some of
our projects. Where to discuss my findings and is there someone interested
in reviewing patches adding the missing dependencies to 'package.json'
files, that would make the repositories compatible with these PMs without
altering npm's behavior?
First I'd start with documenting the current problems we face with npm
and its ecosystem and once we have agreement on that, then beginning to
look for solutions.
Ultimately, I think it's important to remember that npm is a proprietary
service run by a for-profit company (formerly npm inc., now Github).
We're always going to be fighting against them with little ability to
cause significant change. I think a free software, community based
registry, like practically every other major language, could do so much
better in this area.
-- Legoktm