Re: [SRI] unsupported hashes and invalid metadata

Without thinking about it too hard, I'd vote for merging the "fail closed"
variant (https://github.com/w3c/webappsec/pull/120).

We don't have a good way of distinguishing an awesome new hash function
that we don't yet support, and a bad old hash function that we don't want
to support without compiling a blacklist. I'd prefer not to do that.

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Dec 24, 2014 at 2:45 AM, Francois Marier <francois@mozilla.com>
wrote:

> I've opened an issue around invalid metadata and unsupported hashes:
>
>   https://github.com/w3c/webappsec/issues/119
>
> as well as opened two pull requests for resolving the ambiguity:
>
>   https://github.com/w3c/webappsec/pull/86
>   https://github.com/w3c/webappsec/pull/120
>
> The gist of the issue is what should we do with an integrity attribute
> like:
>
>   <script src="..." integrity="ni:///sha-1024;...">
>
> Should it be ignored and the script loaded as with non-SRI enabled
> browsers (as if the integrity attribute wasn't there)?
>
> Or should it be ignored and cause the script to be blocked?
>
> I can personally see arguments both ways, so I'm curious what others think.
>
> Francois
>
>
>