W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: [SRI] unsupported hashes and invalid metadata

From: Mike West <mkwst@google.com>
Date: Fri, 26 Dec 2014 13:58:53 +0100
Message-ID: <CAKXHy=dOAro=_w8HyWgh2+oPNeGR4e+T+6FQKkR91vx=v==Z=Q@mail.gmail.com>
To: Francois Marier <francois@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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 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
(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>

> 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
Received on Friday, 26 December 2014 12:59:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC