Technical decision making/Decision records/T249299

Decision
Resource: https://www.atlassian.com/blog/inside-atlassian/make-team-decisions-without-killing-momentum

= Appendix =

So.. what is it about Webpack?

 * see this Phab comment
 * see this blog post

Unaudited
Webpack is one of several popular JavaScript bundlers. It, or its hundreds of npm dependencies, have not been reviewed by Security. As such, it is not (currently) ready for use.

Other local tools
It is not unheard of for development to involve unaudited software. In WMF CI and our local development containers, we use "npm-test" and "composer-test" utilities to download and execute unaudited PHP and JavaScript programs (such as PHPUnit, ESLint, WebdriverIO, etc.). These carry a low risk because their scope is naturally limited to informing code review and QA only. They do not run in production or on end-user devices. They do not create executable artefacts that run in production or on end-user devices. These utilities only need to run in an isolated container with read-only privileges to a code base, and then produce an informative signal about whether our tests are passing. At worst, these might wrongly signal that our own code is good to go. They don't transform or introduce executable code.

Webpack is different. It executes hundreds of unaudited packages. Packages that even upstream Webpack won't know of or have reviewed (due to npm's indirect version resolution). Webpack's output file includes our own source code plus executable code generated by or embedded from those unaudited npm packages. Developers are then meant to attach this obscured file to their Git commit and deploy it blindly. All without having reviewed either the npm programs, or its output.

Other bundlers
There are tons of npm packages written in a responsible manner suitable for production, such as Vue.js, Preact, Svelte, Rollup, etc. (Rollup is also used by upstream Vue.js for their own releases). These tend to have few or no external dependencies, and dependencies they do have are generally well-known, easy to audit, and have no further indirect dependencies.

Packages like this can be audited, and deployed via libs/, vendor/ or as their own repo/standalone service. See the Medium-term decision requirements for more details on what such a service could look like.

Packages like Webpack are quite different and consume the part of the npm ecosystem that's quite different in their principles. Packages that literally accept pull requests to remove one line of code in favour of an unfamiliar package with further dependencies, published shortly beforehand and carelessly updating them regularly to newer versions. Such "careless" updating isn't unheard of. After all, it's normal to install updates from a moderated repository such as Debian, Ubuntu, or your Mac/Windows operating system updates. These have a chain of trust that ends with a link between you and the distributor. There is no such link with NPM. NPM is effectively just a public FTP server, like GitHub. Anyone can submit anything, and there is no established practice or concept of trust in its operation. Hence, we must treat npm packages the same way we'd php-composer packages and JS libraries we use in production today. They require locally-owned redistribution and review of their source code. See the Medium-term decision requirements for more details on this.

Cross-team collaboration and productivity
Beyond the above security concerns, using Webpack in the specific way proposed also harms productivity as every patch conflicts with every other patch. Developers would have to rebase a patch each time before being able to rerun its tests or perform code review, as well as to download the patch locally and re-generate build artefacts as part of every rebase (which we do in an isolated container, especially if you have prod access).

Patchability
Webpack artefacts are currently monolithic and effectively binary, this means the workflow is incompatible with WMF backport and security deployment procedures. No patch can be cherry-picked. No patch can be reviewed in a private bug report, or transferred between production branches. Each subsequent week, requires re-patching every bug, first installing the insecure toolkit locally, and then committing this unreviewed binary to production without any tests. Last month, an XSS security issue was found in MobileFrontend. It proved rather difficult to patch, and actually motivated developers involved to disclose the vulnerability ahead of the general security release schedule, because carrying the security patch forward each week was impractical (T262213, Sam Reed, Security).