Subresource integrity / filename hash inconsistency

[karptonite]

Versions

Angular CLI: 1.6.3
Node: 9.3.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router

@angular/cli: 1.6.3
@angular-devkit/build-optimizer: 0.0.36
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.42
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.3
@schematics/angular: 0.1.11
@schematics/schematics: 0.0.11
typescript: 2.5.3
webpack-bundle-analyzer: 2.9.2
webpack: 3.10.0

AND

Angular CLI: 1.6.4
Node: 9.3.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router

@angular/cli: 1.6.4
@angular-devkit/build-optimizer: 0.0.38
@angular-devkit/core: 0.0.25
@angular-devkit/schematics: 0.0.48
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.4
@schematics/angular: 0.1.13
@schematics/schematics: 0.0.13
typescript: 2.5.3
webpack-bundle-analyzer: 2.9.2
webpack: 3.10.0

Repro steps

I don't have a minimal reproduction, but here is a gist to two yarn lockfiles:
https://gist.github.com/karptonite/925a56d957a34ff65063d52e619f7fcc

Observed behavior

when building with --prod --subresource-integrity:
The subresource integrity SHA hash can change without the hashed filename changing as dependencies are updated.

In the two yarn lockfiles shown, nothing that is included in polyfills changed, and the hashed filename (--output-hashing all, since --prod is set) remains unchanged between builds. However, because some other dependencies were updated (notably, the uglify version changed), the integrity SHA hash changed. That is a problem because our js is served by a CDN, which assumes that if the filename remains unchanged, it can continue to serve from the cache.

Desired behavior

When anything that can affect the content of the minimized file changes, that should change the filename hash. This could be accomplished by naming the file based on the minimized code, but it could also be as simple as hashing in the version numbers of the relevant packages involved in minimizing the code when generating the filenames.

If you are unable to reproduce this, let me know, and I'll see if I can figure out how to reproduce it. I got stuck (working in a minimal project) trying to force yarn to downgrade the version of uglify to match what is in my production yarn lock above.

[karptonite]

@clydin, this might be of interest to you.I believe you did the original SRI implementation?

[KLuuKer]

This is not a problem with SRI but really with the cache busting code, you can see this because SRI is actually doing it's job correctly (blocking code that has a incorrect hash value).

I think the cache bust calculator hashes the files BEFORE processing (ugilfy\etc) instead of after all the conversions have been run.

We basically have this problem every time we deploy because the polyfills file always stays the same but the versions of ugily and the like change (because we very aggressively update all dependancies)

[KLuuKer]

can we get this fixed soon? I know it's "inconvenient" and we can clear the cloudflare cache when it happens but.....
when doing daily deploys with about 100 different domains it's getting past the point of "inconvenient" and more like a royal pain in the ass.
o yeah then there is the whole issues of telling everyone to clear their cache because their browser is caching the files for a year.

[nrandell]

I've had similar issues and am currently trying a postbuild script in my package.json to update the runtime file in the html. A bit of a hack, but it may solve the problem.

const path = require('path');
const fs = require('fs');

const cheerio = require('cheerio');
const ssri = require('ssri');

const baseDir = 'dist/newu-app';

const htmlSource = path.join(baseDir, 'index.html');
const markup = fs.readFileSync(htmlSource).toString();
const $ = cheerio.load(markup);

$('script').each((index, element) => {
    const src = $(element).attr('src');
    if (src.startsWith('runtime.')) {
        const filename = path.join(baseDir, src);
        const data = fs.readFileSync(filename);
        const md5 = ssri.fromData(data, {algorithms: ['md5']}).hexDigest();
        const integrity = ssri.stringify(ssri.fromData(data, {algorithms: ['sha384']}));
        const newSrc = 'runtime.' + md5 + '.js';
        const newFilename = path.join(baseDir, newSrc);
        $(element).attr('src', newSrc);
        $(element).attr('integrity', integrity);
        fs.copyFileSync(filename, newFilename);
    }
});

const html = $.html();
fs.writeFileSync(htmlSource, html);

It seems to work for me and may help others

[JohanLindvall]

We are being hit by this bug too.

Consider that the runtime.js file may be in the end user's browser cache so that purging the CDN cache doesn't help.

[clydin]

Can you provide the version of webpack being used in the projects exhibiting the issue?

[nrandell]

I'm using angular cli 7.0.5 and it has pulled in webpack 4.19.1

[clydin]

Webpack 4.19.0 was supposed to fix the runtime chunk hashing.

Is version 4.19.1 the only version present within the project (npm ls webpack)?

Webpack is responsible for generating the filename and the hash used inside it (which is very different than the SRI hash).

[nrandell]

Just checked

npm ls webpack returned

`-- @angular-devkit/build-angular@0.10.3
  `-- webpack@4.19.1

I also have subresourceintegrity and service workers enabled.