WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(11.60 KB, patch)
2021-12-11 14:58 PST
,
Patrick Griffis
no flags
Details
Formatted Diff
Diff
Patch
(11.17 KB, patch)
2021-12-11 14:59 PST
,
Patrick Griffis
no flags
Details
Formatted Diff
Diff
Patch
(12.56 KB, patch)
2021-12-12 10:23 PST
,
Patrick Griffis
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Patrick Griffis
Comment 1
2021-12-10 11:19:43 PST
Created
attachment 446767
[details]
Patch
Patrick Griffis
Comment 2
2021-12-10 11:21:32 PST
Comment hidden (obsolete)
This isn't quite ready as testing locally `run-minibrowser` passes all tests for encoding, yet `run-webkit-tests` fails on the non-UTF-8 ones. I didn't see any relevant env vars or anything that should affect encoding.
Patrick Griffis
Comment 3
2021-12-11 14:58:07 PST
Created
attachment 446903
[details]
Patch
Patrick Griffis
Comment 4
2021-12-11 14:59:07 PST
Created
attachment 446904
[details]
Patch
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
Created
attachment 446935
[details]
Patch
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
<
rdar://problem/86643075
>
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.
Top of Page
Format For Printing
XML
Clone This Bug