Tags are injected with integrity="undefined" on v1.5.0

I’m on Webpack 4.44.2 and noticed after upgrading to this plugin’s v1.5.0 release that injected tags have an undefined integrity. Tags inserted via html-webpack-plugin have the correct integrity, but dynamically injected tags use undefined and the integrity check is bypassed.

Here’s what Firefox prints:

The script element has a malformed hash in its integrity attribute: "undefined". The correct format is "<hash algorithm>-<hash value>".

There are no errors or warnings printed during Webpack’s build.

Downgrading to 1.4.1 fixes this issue so I’m assuming it’s related to the changes that added Webpack 5 support in 1.5.0.

[jscheid]

Ok, I’ve spent some time reflecting on what went wrong here, and the bottom line is:

1. Despite an extensive battery of tests, one important test for this particular case was missing.
2. Considering the scope of the changes for 1.5.0, it would have been wise to publish a release candidate first, to allow the community to uncover potential issues, as we’ve done in the past.
3. We’ve also come to rely too much on the automated test suite and didn’t do enough smoke testing.

I’m planning to take the following steps to reduce the likelihood of something like this happening again:

1. While we should now have tests to ensure (correct) integrity values are added in all cases, these tests are somewhat brittle (eg. the test added for this issue might fail for a reason other than integrity mismatch and would then trigger a false positive.) I’m going to add additional, more robust, test cases for the core functionality over the coming days.
2. The code for loading dynamic chunks at runtime should raise an error when a matching integrity value can’t be found, instead of relying on browser behaviour or the test suite catching all issues. There is a small chance that this might break existing code, but really SRI is pointless unless all code loaded dynamically is protected, and so this seems a good change. This will effectively be an additional fail-safe for this particular issue.
3. We’re going to establish a release protocol that explicitly includes smoke testing on a (small) range of browsers.
4. Future releases with extensive changes will first see release candidates again.

In addition, time permitting, I’m thinking of starting work on a version 2.0.0 that would be a rewrite in Typescript, and drop compatibility with Webpack < 5 (and probably also html-webpack-plugin < 5) which would further help to improve code quality by reducing footprint.

We’re also going to establish a security policy, including a communications channel that can be used for reporting security issues privately.

[jantimon]

@jscheid that sounds awesome 😃

I talked to the webpack core team and they told me that they will probably provide us with additional stages so that we can built the html at time where the css & js files have been optimized and you can generate the correct hashes…

I’ll keep you posted 😃