(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)
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•1 year ago
|
Comment 1•1 year ago
|
||
Trying to see if the CRASH annotations are still valid: https://treeherder.mozilla.org/jobs?repo=try&revision=2858277c9d51cb52ca69baf3bf062b3f5dc86203
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 2•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year 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•1 year ago
|
||
Before it was hard to understand.
| Assignee | ||
Comment 9•1 year ago
|
||
Before it was hard to understand.
| Assignee | ||
Comment 10•1 year ago
|
||
Another test for an adoption from a TT realm is added in another part.
The renaming makes their relationship clearer.
| Assignee | ||
Comment 11•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•1 year ago
|
||
Comment 14•1 year ago
|
||
| bugherder | ||
Comment 16•1 year 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•1 year ago
|
||
| Assignee | ||
Comment 18•1 year ago
|
||
Makes clearer what's meant.
| Assignee | ||
Comment 19•1 year ago
|
||
| Assignee | ||
Comment 20•1 year ago
|
||
One step towards fixing https://github.com/w3c/trusted-types/issues/494.
Comment 21•1 year ago
|
||
Comment 23•1 year ago
|
||
| bugherder | ||
Comment 25•1 year ago
|
||
| Assignee | ||
Comment 27•1 year 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•1 year 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•1 year 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•1 year ago
|
||
| Assignee | ||
Comment 31•1 year ago
|
||
| Assignee | ||
Comment 32•1 year 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•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 34•1 year 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•1 year ago
|
||
Comment 36•1 year ago
|
||
| bugherder | ||
Comment 38•1 year ago
|
||
| Assignee | ||
Comment 40•1 year ago
|
||
| Assignee | ||
Comment 41•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 42•1 year ago
|
||
| Assignee | ||
Comment 43•1 year ago
|
||
Preparation for reusing it in a following part.
| Assignee | ||
Comment 44•1 year ago
|
||
Updated•1 year ago
|
Comment 45•1 year 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•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Comment 47•1 year ago
|
||
| Assignee | ||
Comment 49•1 year 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•1 year ago
|
||
It timeouts in Chrome and Gecko. Removing creating the policy lets it
pass.
Updated•1 year ago
|
| Assignee | ||
Comment 51•1 year 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•1 year ago
|
||
| bugherder | ||
Comment 53•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 54•1 year 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•1 year ago
|
||
| bugherder | ||
Comment 57•1 year 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•1 year 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•1 year ago
|
Comment 59•1 year 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•1 year 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•1 year 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•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 62•1 year 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•1 year 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
•