The other day, I was going through this medium post which describes the kind of chaos and insecurity currently plaguing the JavaScript world, and the numero uno reason for that is the astronomical number of npm packages.
When you usually install a non-trivial library or application through a package manager, the expectation is that the number of dependencies should be as less as possible. This not only helps you in managing the disk space (very important for cloud hosting), but also makes a manageable code audit possible. For instance, the Python’s Flask package (which is a considerably large web framework, a lot more complex than Webpack which is just a JavaScript bundler) has the following four dependencies:
install_requires=[ 'Werkzeug>=0.14', 'Jinja2>=2.10', 'itsdangerous>=0.24', 'click>=5.1', ],
On the other hand, this trivial Webpack package on NPM has 25 dependencies on various 3rd party packages!!
@webassemblyjs/ast @webassemblyjs/helper-module-context @webassemblyjs/wasm-edit @webassemblyjs/wasm-opt @webassemblyjs/wasm-parser acorn acorn-dynamic-import ajv ajv-keywords chrome-trace-event enhanced-resolve eslint-scope json-parse-better-errors loader-runner loader-utils memory-fs micromatch mkdirp neo-async node-libs-browser schema-utils tapable uglifyjs-webpack-plugin watchpack webpack-sources
However, your worry hasn’t even started yet, your real worry starts when you realize that the other super-trivial package mentioned in that article called is-odd has a whopping statistics of 1.4 million downloads per week:
Now, any programmer worth his salt will know that its a one line coding effort to determine whether a given number is odd or even, even in JavaScript:
function isEven(n) {
return n % 2 == 0;
}
function isOdd(n) {
return Math.abs(n % 2) == 1;
}Now, our master programmer who developed this “is-odd as a service” not only goes ahead and registers whole new npm packages called is-odd and is-even, but also makes a lot of his other packages depend on it. Can you even begin to imagine what kind of bureaucratic politician you have to be in order to do that!
Now, this in itself couldn’t have caused any problem, the real issue here is that the highly reputed and popular Webpack project is also using one of his packages (for doing a trivial regular expression check on a string) and the dependency chain is such that the following four packages are also pulled in whenever you install Webpack from npm since Webpack depends on them (and this is what explains is-odd’s 1.4 million weekly download figure):
is-odd -> nanomatch -> micromatch -> webpack
Now, even a CS undergraduate should be able to see the management nightmare, not only of burdening your hard disk space of these additional packages whenever you npm install webpack, but also the security nightmares associated with it. In future, if the developer of is-odd package clubbed some malware in his code and propagated it throughout the node-ecosystem, can you even begin to imagine the disaster its going to cause on your production machines? I agree that this applies to other packaging systems like pip and composer too, but problem here is that the number of npm packages is too large and too unmanageable.
And to top it, the developers in the ecosystem are paying no heed to this, they think this is something to be proud of and worthy of chest thumping. They should try to understand that DRY (Don’t Repeat Yourself) becomes a self-harming pattern beyond a certain extent, especially when you start releasing packages like is-odd and is-even. They get argumentative and counter you with a militant defense when you try to explain this point to them. For instance, I raised an issue on Webpack’s Github repository a few days ago for this exact problem (remove dependency from micromatch package) and they simply closed it down giving some hilarious arguments. Their arguments are really interesting, but beyond sanity for someone who values security and maintainability of production applications.
| Published on Web Code Geeks with permission by Prahlad Yeri, partner at our WCG program. See the original article here: Webpack Project is sitting on a vulnerability, avoid it at all costs! Opinions expressed by Web Code Geeks contributors are their own. |
That’s why you put pre-built apps/bundles on production systems. Is anyone really that light-headed to run the building/assembly/packing process on a production system? Node, NPM and related tools are a foreign concept on ours. I can’t even begin to imagine what kind of punishment we would face from security if we did as the author suggests in the article (really? running NPM in production? REALLY?). And we don’t have to worry about those billions of packages on a production system either.