RESOLVED FIXED 234159
CSP: Always use UTF-8 encoded content when checking hashes
https://bugs.webkit.org/show_bug.cgi?id=234159
Summary CSP: Always use UTF-8 encoded content when checking hashes
Patrick Griffis
Reported 2021-12-10 11:18:50 PST
CSP: Always use UTF-8 encoded content when checking hashes
Attachments
Patch (4.31 KB, patch)
2021-12-10 11:19 PST, Patrick Griffis
no flags
Patch (11.60 KB, patch)
2021-12-11 14:58 PST, Patrick Griffis
no flags
Patch (11.17 KB, patch)
2021-12-11 14:59 PST, Patrick Griffis
no flags
Patch (12.56 KB, patch)
2021-12-12 10:23 PST, Patrick Griffis
no flags
Patrick Griffis
Comment 1 2021-12-10 11:19:43 PST
Patrick Griffis
Comment 2 2021-12-10 11:21:32 PST Comment hidden (obsolete)
Patrick Griffis
Comment 3 2021-12-11 14:58:07 PST
Patrick Griffis
Comment 4 2021-12-11 14:59:07 PST
Patrick Griffis
Comment 5 2021-12-11 15:00:01 PST
Still not sure why running the browser directly has different results, however this certainly is more in-line with the spec and passes more WPT tests.
Patrick Griffis
Comment 6 2021-12-12 10:23:11 PST
Patrick Griffis
Comment 7 2021-12-12 11:49:16 PST
The test failure really only happens when running via WebKit's HTTP server. For example: `hash-always-converted-to-utf-8/iso-8859-1.html` - `wpt serve` succeeds. - https://wpt.live succeeds. - `run-webkit-httpd` fails. So its something specific to how the tests are run. I would assume its not specific to the HTTP server as macOS and GTK have different servers that both fail.
Patrick Griffis
Comment 8 2021-12-12 11:53:31 PST
> So its something specific to how the tests are run. I would assume its not > specific to the HTTP server as macOS and GTK have different servers that > both fail. Sorry forgot to mention that the issue is in the raw data received at the HTTP layer. libsoup logs this as incoming HTTP data: `run-webkit-httpd`: > <!-- ? (micro sign) has the value of 0xB5 in latin-1 and of 0xC2B5 in utf-8 but the hash value should be the same as the utf-8 computed one --> https://wpt.live: > <!-- \xb5 (micro sign) has the value of 0xB5 in latin-1 and of 0xC2B5 in utf-8 but the hash value should be the same as the utf-8 computed one --> So the browser gets already invalid data from the HTTP server.
Radar WebKit Bug Importer
Comment 9 2021-12-17 11:19:17 PST
Kate Cheney
Comment 10 2021-12-20 10:44:49 PST
Comment on attachment 446935 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=446935&action=review r=me. Could you file a bug about the unexpected http server results? > Source/WebCore/page/csp/ContentSecurityPolicy.cpp:-371 > - // FIXME: Compute the digest with respect to the raw bytes received from the page. We should remember to mark this bug resolved once this patch lands.
EWS
Comment 11 2021-12-20 12:14:07 PST
Committed r287270 (245426@main): <https://commits.webkit.org/245426@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 446935 [details].
Brent Fulgham
Comment 12 2022-02-08 15:50:28 PST
This change should be present in STP 139, iOS 15.4 Beta, and macOS 12.3 Beta.
Note You need to log in before you can comment on or make changes to this bug.