5.0.0-alpha.4 generates wrong integrity hash with mini-css-extract-plugin

[zlk89]

Repro

1. git clone and go to this branch sri-breaks-css: https://github.com/zlk89/webpack-reprods/tree/sri-breaks-css
2. yarn
3. yarn start and go to http://localhost:8080/, you can see an error on console:

 Failed to find a valid digest in the 'integrity' attribute for resource 'http://localhost:8080/297c2bb7ca06bdef00bd.css' with computed SHA-256 integrity 'x6erygV386tuxc7xPDZhRB5YQgrXe7VtRCH5hD4GW6E='. The resource has been blocked.

4. Downgrade webpack-subresource-integrity to 5.0.0-alpha.3 and yarn to reinstall dependency
5. yarn start again, and it works now

This appears to be related with the contenthash fix in 5.0.0-alpha.4, because this only happens when:

• 5.0.0-alpha.4
• use contenthash in mini-css-extract-plugin
• use realcontenthash
• enable sourcemap

[jscheid]

@sokra any thoughts here? The only change in alpha.4 is the one you suggested (return undefined instead of old hash.)

[sokra]

Could you try if this still happens without source map

[zlk89]

Hi @sokra as described in the issue, one required condition to trigger this bug is to enable sourcemap. So if sourcemap isn't enabled, then it works fine.

[sokra]

The circular hashes between source map and source file are the problem. Impossible to calculate a real hash for both. We need to add something to enforce the real hash for the source file. Or flag real hash as lower prio for the source map.

[jscheid]

@sokra it sounds like you're going to address this in Webpack core, or does this need any changes in this plugin?

[zlk89]

Hmm the interesting thing is that this bug doesn't happen to style-loader, not sure if it is an issue on mini-css-extract-plugin

[sokra]

Ok I looked into it and actually there are not circular hashed between source map and source file. It seems like the CSS files doesn't have the integrity hash as contenthash assigned:

{
  name: 'b889e1ba43a9c2cedf00.css',
  info: {
    immutable: true,
    contenthash: 'b889e1ba43a9c2cedf00', // <- should have sha384-xxx too
    related: { sourceMap: 'b889e1ba43a9c2cedf00.css.map' }
  }
}
{
  name: 'b2f889db6a359d6a1a1c.js',
  info: {
    immutable: true,
    contenthash: [
      'b2f889db6a359d6a1a1c',
      'sha384-5ruMSp2sdmmRtL7cKVhgqlSgO5rYBuCaibAe4mmpY9H/pbsQ3AgMBi8+u219OWUL'
    ],
    javascriptModule: false,
    related: { sourceMap: 'b2f889db6a359d6a1a1c.js.map' }
  }
}
{
  name: 'b67a15d8a56c7a15fa8a.js',
  info: {
    immutable: true,
    contenthash: [
      'b67a15d8a56c7a15fa8a',
      'sha384-b4OsdIpcVoFLjHucP2gaQbhppOEDvcSYPPKeAbpqgbf9gpi22zFuEJE0RARcDEEJ'
    ],
    javascriptModule: false,
    related: { sourceMap: 'b67a15d8a56c7a15fa8a.js.map' }
  }
}
{ name: 'b889e1ba43a9c2cedf00.css.map', info: { development: true } }
{ name: 'b2f889db6a359d6a1a1c.js.map', info: { development: true } }
{ name: 'b67a15d8a56c7a15fa8a.js.map', info: { development: true } }
{ name: 'index.html', info: {} }

[jscheid]

@sokra thanks for digging into this, not entirely sure why this bug was revealed only by that latest change.

@zlk89 could you test with the branch I've just pushed? Should work better now.

[zlk89]

@jscheid verified that it works!

[jscheid]

Thanks for checking. Fix released in v5.0.0-alpha.5.