[valenterry]

Well, to be honest, the browsers could super easily solve that. In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. This is a huge security risk. Read more here" and that's it. Then you can just add the script, run the site, check the logs and add the hash, done.

[sirl1on]

You can define a CSP header to only exec 3rd Party scripts with known hashes

[valenterry]

But that doesn't make it easy to integrate a new script from an author who doesn't provide the hash already.

[no_wizard]

Vendor your dependencies. It’s better for you as a maintainer anyway, since caching only works[0] with first party domains with any reliability.

And once you vendor your dependencies you can calculate the hash yourself

[0]: there are caveats to this

[TZubiri]

How would third party distribution like a cdn affect hashing?

I think https and integrity hashes address two very orthogonal attack vectors.

[0xCMP]

Because if you're not getting the real benefit (improved response times due to caching) you can stop worrying about hashing it properly or not and simply serve a copy you know to be good (or at least known and probably version controlled). Now you don't need to hash or know which hash is correct or worry about the user getting served the wrong file because someone else got hacked.

[TZubiri]

Not sure I follow, how does hashing mean you lose improved response times or caching?

Do you mean that hashing the file takes time? I guess that can be significant, but it's probably 2 or 3 cycles per byte, and average js size is like 10kb tops? 30khz doesn't look like much, it's a millionth of a second.

[no_wizard]

It’s about control foremost. If you vendor your dependencies you know what you’re serving and can calculate the hash and use it in your CSP, and provides more stability for versioning.

Plus, as mentioned, only 1st party origins enjoy any benefits of caching content for faster load times so you get an additional benefit

[TZubiri]

But you can .. get the hash yourself?

wget url; sha256 file

[valenterry]

Of course you can. But when it comes to security, one thing is very important in practice: making the secure way of doing things as easy as possible.

So, why did you not actually post the correct shell script? Apparently that would have been more effort to get right and ensure is correct right? And also work for every OS. And there you have it: if someone first has to figure out which script to run, some percentage will give up here. And that's my point: the browser should make it as easy as possible to avoid that from happening.

[account42]

Cool. Now your site will break if the upstream pushes a fix while you're on vacation.

[bastawhiz]

> In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined.

How does the browser know which files to warn you about? What about scripts that are generated dynamically and have no static hash? There's plenty of reasons why you wouldn't want this.

[valenterry]

It just warns about all embedded non-same-origin scripts that don't have a hash.

> What about scripts that are generated dynamically and have no static hash?

Well, then the warning is still valid because this is a security risk. I guess it'd be fine to be able to suppress the warning explicitly in those cases.

> There's plenty of reasons why you wouldn't want this.

For example? Honestly curious where you would not want a warning by default.