Failed to find a valid digest in the 'integrity'

[BrunoQuaresma]

When i run the build command and upload my files to server this error appears in mobile browsers:

Failed to find a valid digest in the 'integrity' attribute for resource 'http://facilbardelivery.com.br/static/css/main.33fa5f7d.css' with computed SHA-256 integrity 'fhBe+EZQ6zPH/PQFiIlVZjwvoWQGAWe1s8BEyp2TJ6k='. The resource has been blocked.

[gaearon]

As I noted in the other thread, have you followed these instructions? Could that be the reason it is failing?

[BrunoQuaresma]

Yes, I followed the instructions. In PC browser works fine (facilbardelivery.com.br) but in chrome(for android) not. However, when I test the app in Heroku (facilbar.herokuapp.com) with HTTPS it works even in mobile phone. So, is required use SSL?

[gaearon]

Ugh. I think we’ll have to revert this change because I don’t know how to troubleshoot this. Want to send a PR?

cc @XVincentX

[XVincentX]

Let me dig into - subresource integrity does not require SSL at all.

[Timer]

It sounds like the feature is simply doing what it's intended to do.

Do you have compression enabled in your Chrome for Android browser? Google may be minifiying your CSS before sending it to your phone causing the signature to be invalid.

SSL prevents this from happening. Maybe we should look for https in PUBLIC_URL and toggle this feature based on that.

https://developer.chrome.com/multidevice/data-compression

[Timer]

"The proxy performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which is not essential to the rendering of the page. These optimizations, combined with mandatory gzip compression for all resources, can yield substantial bandwidth savings for the client."

[BrunoQuaresma]

@Timer this is it!!! Thanks! When i disable it works perfectly.

[XVincentX]

That might eventually change the received file which is seen as a resource tampering from the browser.

This is not happening on mobile Safari (just tested on my iPhone)

[BrunoQuaresma]

I think in this mode it does a proxy cache that even with the digest is not invalidated. Even after activating again. The page continues to display correctly.

[Timer]

Actually we could inject a stub which strips resource validation when over HTTP. I'd be more than happy to make a PR if that's what we decide to do.

Currently, this feature is going to cause more pain than benefit because of Chrome compression or ISP compression if they partake in it. We need to do something about it (opt in?) or revert it for now.

[gaearon]

Actually we could inject a stub which strips resource validation when over HTTP.

How would this work? I’d like to see a proof of concept. Either that or let’s roll it back.

[XVincentX]

That's sad, but I understand that it's blocking and annoying :(

[Timer]

How would this work? I’d like to see a proof of concept. Either that or let’s roll it back.

Sorry I was speaking in mere hypotheticals; it's not something I have done before. But the idea would be to check window.location.protocol for https, if not found, scrub the script tags (and css; anything I guess) on the document and remove integrity attributes.

In theory we would inject a script tag before the bundle script tag, and add the defer attribute to them both. This would allow both script tags to be loaded into the DOM before any execution; which in theory would allow us to manipulate the attributes on the second script tag since the script tags should be eval'd synchronously and in order.

^ sound crazy enough to work?

[Timer]

I think the best plan of action currently would be to remove usage of the plugin until we can find a work around or make it opt-in. I would like to see an issue tagged discussion for this.

[gaearon]

Happy to take a PR removing it until we figure out what to do.

[Timer]

😢 PR https://github.com/facebookincubator/create-react-app/pull/1233

[gaearon]

Closing via #1233, please feel free to open new issues / PRs if you have ideas on how to add this back.

[gaearon]

Should be fixed in react-scripts@0.8.4. Please verify. https://github.com/facebookincubator/create-react-app/releases/tag/v0.8.4

[jscheid]

😢

I'm going to add language to our README to clarify this point, current draft is here: https://github.com/waysact/webpack-subresource-integrity/pull/25

See also https://bugs.chromium.org/p/chromium/issues/detail?id=642928

[Timer]

Cool, @jscheid! I was not aware of this.

[jscheid]

sound crazy enough to work?

@Timer It's a clever hack! :-) Unfortunately, inline scripts don't play nice with CSP, and conceivably there's a large overlap between folks who'd want to use SRI and those who'd want to add a CSP.

Theoretically it's possible to white-list inline scripts with CSP, but that's not exactly straightforward. I think at that point you're better off just setting Cache-Control: no-transform.

Of course, with a non-inline script it becomes a catch 22 if you do use SRI for it, and Achilles' heel if you don't :-/ Not to mention the extra HTTP request.

There's also potential issues for people with JS disabled or ad blockers, considering that SRI also affects CSS loading. I believe CSP is already a show-stopper here so probably not worth elaborating on this.

[jscheid]

For the record, I wasn't aware of this problem either before today or I would have let you guys know. (When I said "clarify this point" above, perhaps it made it sound like I knew about this before, but I didn't.)

[gaearon]

Yea no worries. Today we learned. :-)

[XVincentX]

Me too - I didn't really think there were so many consequences.

[kornelski]

I've tested compression proxies a while ago, and they all respected Cache-control: no-transform (I've focused on images, but scripts are compressed by the same products).

[ghost]

In the Ember world they have default SRI with no problems. It's more clear today what exactly is the problem?

It's a problem also for this kind of issues: https://www.troyhunt.com/im-sorry-you-feel-this-way-natwest-but-https-on-your-landing-page-is-important

[tasn]

Given the prevalence of https, is this even still an issue? I'm happy to do the work needed to make it an opt-in if someone could direct me to an example of how an opt-in feature looks like in create-react-app or what is the recommended way of doing it.

I recently created a browser plugin that verifies the pgp signature of a page. It relies on subresource-integrity to also validate external scripts and styles.

I need it for the EteSync web app (uses react-based web app), and I'd rather not eject just to add this.

[tasn]

Furthermore, one way of fixing those applications that break because of subresource integrity is just make them change the resource uri scheme from "://" to "https://", making sure that subresources are always loaded from an encrypted source and thus won't be mangled by evil proxies.