Sigh Webpack… You’ve been my go-to bundler in the world of Javascript for quite some time, but the other day you really threw me for a loop. There’s a project that’s on Node 16 LTS, and the Node LTS recently switched to version 18 a few months ago, so I saw it as an opportunity to update the Volta config in the package.json of this project. I knew that bumping to Node 18 would lead to the ERR_OSSL_EVP_UNSUPPORTED issue being thrown and in my mind I had the NODE_OPTIONS=--openssl-legacy-provider in the package.json scripts solution in my back pocket.

“No need to do that hacky solution”, is what I told myself knowing source of the issue. The source being that the default (and extremely ancient) md4 algorithm was still being used by Webpack 4. Yes, the same md4 that had its first hash collision publicly published in 2007; about 16 years now since time of writing.

However, Webpack has a way to override the hash function. “I’ll do that, that’s far less hacky.”, is what I thought. So I threw in the following into webpack.config.js:

module.exports = {
    output: {
        // "sha256" or whatever other modern digest functions supported by your current node version
        hashFunction: "sha256"
    }
};

aaaand nope. Got the lovely exit code 1 with the OpenSSL issue spit back out.

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at BulkUpdateDecorator.hashFactory (/app/node_modules/webpack/lib/util/createHash.js:155:18)
    at BulkUpdateDecorator.update (/app/node_modules/webpack/lib/util/createHash.js:46:50)
    at OriginalSource.updateHash (/app/node_modules/webpack-sources/lib/OriginalSource.js:131:8)
    at NormalModule._initBuildHash (/app/node_modules/webpack/lib/NormalModule.js:888:17)
    at handleParseResult (/app/node_modules/webpack/lib/NormalModule.js:954:10)
    at /app/node_modules/webpack/lib/NormalModule.js:1048:4
    at processResult (/app/node_modules/webpack/lib/NormalModule.js:763:11)
    at /app/node_modules/webpack/lib/NormalModule.js:827:5 {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
command terminated with exit code 1

Hmm, ok. So… maybe, when I ran openssl --help on the Mac it gave me a list of digest algorithms supported by that OpenSSL version, but not by the one that Node 18 is pointing to. So, I proceeded to lower the digest algorithm down ever further down the time hole to sha1.

..aaaand ERR_OSSL_EVP_UNSUPPORTED again. Wat, really? No way Node 18 dropped support for sha1. I mean, sure, a collision for sha1 was found back in 2017 (about 6 years since time of writing), but md4 hung around for 14 years. So what’s going on? I had to dive deeper as this was bugging me.

So after for some time, I finally found the issue in webpack/lib/util/createHash.js.

aaaaaaahhhhh (╯°□°)╯︵ ┻━┻

Webpack 4 has md4 hardcoded as the digest algorithm in their call to the webpack optimizer. I either have to add an env var (NODE_OPTIONS=--openssl-legacy-provider) to downgrade the OpenSSL version used and thereby also the digest function used, upgrade to Webpack 5 (which is a different pain in the butt), or publish some alt version of webpack to make the update of 20+ projects easier.

It’s irritating because there’s a config option to change the hashFunction, but now digging into it, it seems that the option is not globally applied.

So, dragged my feet and I defaulted to the hacky NODE_OPTIONS=--openssl-legacy-provider for the time being.

I’m pretty disappointed to see a project that’s core to the JS ecosystem hardcode a value like that, specially when they also claim to provide a way to override it.

I mean… I don’t think it to be from lack of sponsors? They seem to be rather padded in that realm.

Regardless, I’ve been wanting to hop off of tools built in JS for web development for a while now. They’re slow compared to solutions like ESBuild (built in Go) and Parcel 1 & 2 (built in Rust) plus those download over NPM as native binaries for the platform that you’re using. Doesn’t matter what Node version I’m using, that same binary will continue to work for that project.

Perhaps this was just the last nail in the coffin for me to recommend Webpack for any projects post 2023.