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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
