Trunk uses wrong the wrong base64 alphabet for `integrity` hashes about trunk HOT 7 CLOSED

Done.

from trunk.

However, so far I haven't seen an error on this

I also don't see any errors or warnings and most of our users don't have any issues at all. However, we received a bug report recently from a user using Firefox on Linux where the page does not load at all due to invalid characters in the integrity hash.

from the linked docs, I can't see that requirement

The grammar in the subresource integrity standard indicates:

base64-value       = <base64-value production from [Content Security Policy Level 2, section 4.2]>

Then you can follow the link to the Content Security Policy Level 2, section 4.2 where base64-value is defined as:

base64-value      = 1*( ALPHA / DIGIT / "+" / "/" )*2( "=" )

As you can see in the ABNF, both '_' and '-' are invalid characters.

from trunk.

Should be released as 0.19.2. Thanks for the quick PR!

from trunk.

Thanks for bringing this up. However, so far I haven't seen an error on this (which doesn't mean anything), but also from the linked docs, I can't see that requirement. I am sure I am missing something.

from trunk.

There are 2 types of base64 encoding alphabet (the 64 characters used for the 64 base digits). The official alphabet (which is described in RFC4648), use, well the known alphanumeric range + / and +. This alphabet collides with special characters used in URL so another, alternate alphabet is described in the same RFC for an encoding called base64 url. In this base64URL alphabet, the digit / is replaced by _ and the digit + is replaced by -.

This encoding should be used exclusively in URL and not anywhere else.

The issue is that this repository use this alphabet to encode the SHA hash of the subresource integrity while it should be using the former, official alphabet. Browser respecting the subresource integrity specification thus can't decode the hash (since it's encoded with the bad alphabet) and will refuse to load the resource, leading to catastrophic issues (no CSS, no JS, no WASM module loaded).

The specification linked above is clear and explicitely specify to use the alphabet in section 4 of RFC 4648 and not those of section 5.

In the example digest above, instead of

integrity=sha384-0Zy966gMg2P2uZhUAv8IdixXEIejROvJyU28_fbsDk_3geMKyy84V0zSrHs2pN-H

It should have read:

integrity=sha384-0Zy966gMg2P2uZhUAv8IdixXEIejROvJyU28/fbsDk/3geMKyy84V0zSrHs2pN+H

to be correct.

It happens that Chrome actually fallback to base64URL decoding if it fails to decode base64 alphabet (it shouldn't). Firefox doesn't (as it should).

from trunk.

Thanks, that makes it clear! If you can come up with a PR for main, I can backport it and push out a release.

from trunk.

Thanks for the quick release! We'll test this today.

from trunk.