(trusted types) Audit test coverage, making sure that the remaining annotations are timeouts, but not failures
Categories
(Core :: DOM: Security, task, P3)
Tracking
()
People
(Reporter: freddy, Assigned: mbrodesser-Igalia)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [domsecurity-active], [wptsync upstream])
Attachments
(19 files, 3 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Reporter | ||
Updated•7 months ago
|
Comment 1•3 months ago
|
||
Trying to see if the CRASH annotations are still valid: https://treeherder.mozilla.org/jobs?repo=try&revision=2858277c9d51cb52ca69baf3bf062b3f5dc86203
Updated•2 months ago
|
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 2•2 months ago
|
||
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 3•2 months ago
|
||
Regarding the removed TODO: checking one non-null namespace should
suffice, since other non-null namespaces likely take the same codepath.
Assignee | ||
Comment 8•2 months ago
|
||
Before it was hard to understand.
Assignee | ||
Comment 9•2 months ago
|
||
Before it was hard to understand.
Assignee | ||
Comment 10•2 months ago
|
||
Another test for an adoption from a TT realm is added in another part.
The renaming makes their relationship clearer.
Assignee | ||
Comment 11•2 months ago
|
||
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 12•2 months ago
|
||
Comment 14•2 months ago
|
||
bugherder |
Comment 16•2 months ago
|
||
It seems we have done fixed quite a lot of failures since October, compare for example:
- https://hg.mozilla.org/mozilla-central/file/33e502b0f9b19d37b250b7e1d04b3618ec758d6f/testing/web-platform/meta/trusted-types
- https://hg.mozilla.org/mozilla-central/file/a861e5955acebded52e664b0ca290e040fa933fb/testing/web-platform/meta/trusted-types
We need to go over the list of remaining failures and analyze them.
Assignee | ||
Comment 17•2 months ago
|
||
Assignee | ||
Comment 18•2 months ago
|
||
Makes clearer what's meant.
Assignee | ||
Comment 19•2 months ago
|
||
Assignee | ||
Comment 20•2 months ago
|
||
One step towards fixing https://github.com/w3c/trusted-types/issues/494.
Comment 21•2 months ago
|
||
Comment 23•2 months ago
|
||
bugherder |
Comment 25•2 months ago
|
||
Assignee | ||
Comment 27•2 months ago
•
|
||
Update:
- Fixed:
- Remaining to be fixed:
- https://github.com/w3c/trusted-types/issues/526
- https://github.com/w3c/trusted-types/issues/513
- https://github.com/w3c/trusted-types/issues/494
- https://github.com/w3c/trusted-types/issues/568
- https://hg.mozilla.org/mozilla-central/file/d15f84756dc8feca1636cce4a0d164d0f2afd637/testing/web-platform/meta/trusted-types
- https://bugzilla.mozilla.org/show_bug.cgi?id=1937764
Comment 28•2 months ago
|
||
Backed out for causing wpt fails @ block-string-assignment-to-Document-parseHTMLUnsafe.html
- Backout link
- Push with failures
- Failure Log
- Failure line:
TEST-UNEXPECTED-FAIL | /trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html | 'Document.parseHTMLUnsafe(string)' assigned via default policy (successful HTML transformation). - assert_equals: expected "Document parseHTMLUnsafe" but got "Document parseHTMLUnsafe "
Assignee | ||
Comment 29•2 months ago
|
||
(In reply to amarc from comment #28)
Backed out for causing wpt fails @ block-string-assignment-to-Document-parseHTMLUnsafe.html
- Backout link
- Push with failures
- Failure Log
- Failure line:
TEST-UNEXPECTED-FAIL | /trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html | 'Document.parseHTMLUnsafe(string)' assigned via default policy (successful HTML transformation). - assert_equals: expected "Document parseHTMLUnsafe" but got "Document parseHTMLUnsafe "
It's a typo in the actual code (https://searchfox.org/mozilla-central/rev/df850fa290fe962c2c5ae8b63d0943ce768e3cc4/dom/base/Document.cpp#19796). Will fix it in a separate ticket.
Comment 30•2 months ago
|
||
Assignee | ||
Comment 31•2 months ago
|
||
Assignee | ||
Comment 32•2 months ago
|
||
The strings in the production code contain a superfluous whitespace.
No separate issues are filed for fixing those as all failing tests will
be audited according to
https://bugzilla.mozilla.org/show_bug.cgi?id=1907849#c27. That is,
auditing at all test meta files.
Assignee | ||
Comment 33•2 months ago
|
||
Updated•2 months ago
|
Updated•2 months ago
|
Assignee | ||
Comment 34•2 months ago
|
||
A test for Element innerHTML
already exists at
https://searchfox.org/mozilla-central/rev/df850fa290fe962c2c5ae8b63d0943ce768e3cc4/testing/web-platform/tests/trusted-types/default-policy.html#43,74,84.
Assignee | ||
Comment 35•2 months ago
|
||
Comment 36•2 months ago
|
||
bugherder |
Comment 38•2 months ago
|
||
Assignee | ||
Comment 40•2 months ago
|
||
Assignee | ||
Comment 41•2 months ago
|
||
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 42•2 months ago
|
||
Assignee | ||
Comment 43•2 months ago
|
||
Preparation for reusing it in a following part.
Assignee | ||
Comment 44•2 months ago
|
||
Updated•2 months ago
|
Comment 45•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c006cb26e155
https://hg.mozilla.org/mozilla-central/rev/669822cfa2fb
https://hg.mozilla.org/mozilla-central/rev/f21fc5b44dfc
https://hg.mozilla.org/mozilla-central/rev/4d109782995e
https://hg.mozilla.org/mozilla-central/rev/390c5456d7df
https://hg.mozilla.org/mozilla-central/rev/4b9f0161c5ae
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
Comment 47•2 months ago
|
||
Assignee | ||
Comment 49•2 months ago
|
||
"get Trusted Types-compliant attribute value" is called from
setAttribute*
, for links see the test.
setAttribute
and setAttributeNS
presumably take the same code-paths,
so only testing setAttributeNS
here.
For event handlers only one test is added, because other event handlers
presumably take the same code-paths.
Assignee | ||
Comment 50•2 months ago
|
||
It timeouts in Chrome and Gecko. Removing creating the policy lets it
pass.
Updated•2 months ago
|
Assignee | ||
Comment 51•2 months ago
•
|
||
Update of the currently known remaining work for this ticket:
- https://github.com/w3c/trusted-types/issues/526
- https://github.com/w3c/trusted-types/issues/513
- https://github.com/w3c/trusted-types/issues/494:
- The most but potentially not all sinks should now be covered with tests; relevant patches under review: part 17 and part 18 of this Bugzilla ticket.
- Determining an complete list of all sinks is not trivial, for two reasons. Gecko might not cover all sinks currently and the different specs have pending PRs (e.g. https://github.com/whatwg/dom/pull/1268).
- All sinks which currently support Trusted Types in Gecko can be determined via https://searchfox.org/mozilla-central/search?q=%5CbTrustedHTML%5Cb%7C%5CbTrustedScript%5Cb%7CTrustedScriptURL%7C%5CbTrustedType%5Cb&path=*.webidl&case=false®exp=true.
- https://github.com/w3c/trusted-types/issues/568: fixed when the patch of part 17 of this Bugzilla ticket lands.
- https://searchfox.org/mozilla-central/search?q=&path=meta%2Ftrusted-types%2F*.ini&case=false®exp=false
- https://bugzilla.mozilla.org/show_bug.cgi?id=1937764
- https://github.com/w3c/trusted-types/issues/570: fixed when patch of part 18 of this Bugzilla ticket lands.
- https://github.com/w3c/trusted-types/issues/571
- https://github.com/w3c/trusted-types/issues/572
Comment 52•2 months ago
|
||
bugherder |
Comment 53•2 months ago
|
||
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 54•2 months ago
|
||
When continuing writing patches for this issue, consider filing a successor-Bugzilla ticket. In order to avoid affecting multiple releases (https://whattrainisitnow.com/calendar/).
Comment 55•2 months ago
|
||
bugherder |
Comment 57•2 months ago
|
||
It seems some commits have not been upstreamed yet by moz-wptsync-bot. Let's wait that it happens, close this and corresponding github issues and open a follow-up bug.
Comment 58•2 months ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #57)
It seems some commits have not been upstreamed yet by moz-wptsync-bot. Let's wait that it happens, close this and corresponding github issues and open a follow-up bug.
I stand corrected, I didn't realize multiple commits were grouped in a single PR:
https://github.com/web-platform-tests/wpt/pull/49621/commits
https://github.com/web-platform-tests/wpt/pull/49671/commits
https://github.com/web-platform-tests/wpt/pull/49735/commits
https://github.com/web-platform-tests/wpt/pull/49756/commits
https://github.com/web-platform-tests/wpt/pull/49859/commits
https://github.com/web-platform-tests/wpt/pull/49863/commits
Updated•2 months ago
|
Comment 59•2 months ago
|
||
(In reply to Mirko Brodesser (:mbrodesser-Igalia) from comment #29)
It's a typo in the actual code (https://searchfox.org/mozilla-central/rev/df850fa290fe962c2c5ae8b63d0943ce768e3cc4/dom/base/Document.cpp#19796). Will fix it in a separate ticket.
Done in bug 1938069.
(In reply to Mirko Brodesser (:mbrodesser-Igalia) from comment #32)
Bug 1907849: part 11) Add WPTs for checking
setHTMLUnsafe
's trusted types' sink string of the default policy. r=smaug
The strings in the production code contain a superfluous whitespace.
Done in bug 1939802.
Comment 60•2 months ago
|
||
(In reply to Mirko Brodesser (:mbrodesser-Igalia) from comment #51)
- https://github.com/w3c/trusted-types/issues/494:
- The most but potentially not all sinks should now be covered with tests; relevant patches under review: part 17 and part 18 of this Bugzilla ticket.
Thanks for adding these tests, I'll check the remaining ones.
- Determining an complete list of all sinks is not trivial, for two reasons. Gecko might not cover all sinks currently and the different specs have pending PRs (e.g. https://github.com/whatwg/dom/pull/1268).
The spec I checked are at https://github.com/w3c/trusted-types/issues/494#issuecomment-2568807108 ; I'm pretty confident our implementation covers the sinks from these specs as I checked each reference, paragraph and open PRs one by one. I didn't check WebKit/Chromium in details though so some things with fuzzy spec status might have been missed, this happened for execCommand for example which I only found because it had tests.
- All sinks which currently support Trusted Types in Gecko can be determined via https://searchfox.org/mozilla-central/search?q=%5CbTrustedHTML%5Cb%7C%5CbTrustedScript%5Cb%7CTrustedScriptURL%7C%5CbTrustedType%5Cb&path=*.webidl&case=false®exp=true.
Note that this is not enough, some sinks like eval and function constructors are not listed.
Comment 61•2 months ago
|
||
(In reply to Mirko Brodesser (:mbrodesser-Igalia) from comment #54)
When continuing writing patches for this issue, consider filing a successor-Bugzilla ticket. In order to avoid affecting multiple releases (https://whattrainisitnow.com/calendar/).
Closing as opening bug 1939805. Note that I was thinking to have patches to separate bugs blocking bug 1907849 (similarly to what was done with bugs 1934610, 1935594, 1936058) so so we could have kept the meta bug open, but I guess that's ok...
Updated•2 months ago
|
Updated•2 months ago
|
Assignee | ||
Comment 62•2 months ago
|
||
- All sinks which currently support Trusted Types in Gecko can be determined via https://searchfox.org/mozilla-central/search?q=%5CbTrustedHTML%5Cb%7C%5CbTrustedScript%5Cb%7CTrustedScriptURL%7C%5CbTrustedType%5Cb&path=*.webidl&case=false®exp=true.
Note that this is not enough, some sinks like eval and function constructors are not listed.
Right, thanks for pointing that out. One reason is that eval
isn't defined in a .webidl file.
Comment 63•2 months ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #60)
The spec I checked are at https://github.com/w3c/trusted-types/issues/494#issuecomment-2568807108 ; I'm pretty confident our implementation covers the sinks from these specs as I checked each reference, paragraph and open PRs one by one. I didn't check WebKit/Chromium in details though so some things with fuzzy spec status might have been missed, this happened for execCommand for example which I only found because it had tests.
I rechecked completely this morning and commented https://github.com/w3c/trusted-types/issues/494 ; there is one sink missing for Service Workers (which is in its own spec) and another one for SVG script (which is not speced yet).
Description
•