Webpack Project is sitting on a vulnerability, avoid it at all costs!


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:

is odd

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.


Comments !