- From: Luke W Faraone <luke@faraone.cc>
- Date: Thu, 4 May 2017 15:04:06 -0700
- To: Alexander Forbes <axeforbes@uk.ibm.com>
- Cc: public-webappsec@w3.org
Received on Thursday, 4 May 2017 22:04:47 UTC
Alexander, On 4 May 2017 at 13:13, Alexander Forbes <axeforbes@uk.ibm.com <mailto:axeforbes@uk.ibm.com>> wrote: > The spec supports multiple hashes so this should just work, iirc. Can you test? I might be wrong. My confusion here came from the spec stating ..."the user agent will choose the strongest hash function in the list, and use that metadata to validate the response". Basically: "more collision-resistant hashes must always supersede weaker ones". This ends up with some not-very-well-defined behaviour when you have multiple hashes (e.g. having one of each sha512 and sha384 where each represents a different version of the sub-resource). Only the strongest should be checked in this case. I think, in general, you should use some sort of cache-busting / versioned URL, since the version of a JavaScript resource you are loading will probably depend on versions of all the other resources. Otherwise, you're approaching a world of non-determinism and bugs. Could you provide an example use case that would benefit from the freedom you describe? Cheers, Luke
Received on Thursday, 4 May 2017 22:04:47 UTC