最好的尺寸是多少

每 https://w3c.github.io/webappsec-subresource-integrity/#agility ,用户代理将选择列表中最强的哈希函数。

2. 人们真的会期望 哈希匹配而不是全部三个?

不,但就浏览器行为而言:如果最强的散列匹配,那么浏览器使用该散列,而忽略其余的散列(因此其他散列是否匹配也无关紧要)。

3. 提供所有三个哈希值而不是一个哈希值有什么好处吗?

现在的 据我所知,在实践中受益匪浅。那是因为 https://w3c.github.io/webappsec-subresource-integrity/#hash-functions ,一致的用户代理必须支持SHA-256、SHA-384和SHA-512加密哈希函数。

所以呢 目前 ,您只需指定一个SHA-512散列,所有支持SRI的浏览器都将使用该散列。

https://w3c.github.io/webappsec子资源完整性/#敏捷性 指定多个散列函数的功能的目的是在未来的加密发现面前提供灵活性。我们鼓励作者开始迁移到更强大的散列函数,因为它们变得可用。

https://en.wikipedia.org/wiki/SHA-3 或者别的什么)。

因此,由于您需要继续针对较旧的浏览器以及较新的浏览器,因此您将有一段时间针对一些SHA-512是最强哈希函数的浏览器,同时也针对到那时已经出现的新浏览器,这些浏览器将增加对一些SHA-3(或其他)哈希函数的支持。

integrity 价值观。

4. 与#1类似,如果只提供一个哈希值,应该使用哪一个?

据我所知,一个SHA-512值。

Bootstrap )在示例代码中提供sha384值。是不是因为它就在中间,不是太大,不是太小?

我不知道他们为什么选择那样做。但是由于浏览器需要支持SHA-512散列,因此指定SHA-384散列并不能带来任何好处,事实上,您失去了拥有最强散列函数的价值。

5. 出于好奇 正直 <script> 和 <link> .

我特别想知道像这样的多媒体标签 <img> , <source> 等等。

https://w3c.github.io/webappsec-subresource-integrity/#verification-of-html-document-subresources :

注:本规范的未来版本可能包括对所有可能子资源的完整性支持,即:。, a audio , embed , iframe , img , link object script source track ,和 video

但我们还没有到那个未来。