I'm filing this as a security task just in case.
As part of T166010, lots of classes have been moved around and namespaced. Taint-check hardcodes the taintedness information of many MW methods by FQSEN. This logic does not support class aliases, and the FQSENs in taint-check have not been updated. In practice, this means that taint-check no longer knows about "dangerous" methods in MediaWiki. Some hand-tested examples of this:
- OutputPage::addHTML is no longer treated as outputting stuff
- Same for other methods in OutputPage
- WebRequest::getVal is no longer treated as returning a user-controlled value
- Some for the other million getters in WebRequest
- Data about which parameters are safe and which aren't in the various Html:: and Xml:: methods got lost
In practice, this means that XSS detection is pretty much disabled in CI.
Things that could be done:
- Adding the new FQSENs to taint-check
- Making taint-check read class aliases
- Moving the taintedness data to @param-taint and @return-taint annotations in core (T321806)
I believe 3. is the only correct long-term solution. 2. is probably good to have regardless of this (the question is whether it should respect phan's enable_class_alias_support config option). 1. could be done as a temporary measure while we migrate everything.
Another side effect of this bug is that unused suppressions may start appearing all over the place. r960135 is an example where taint-check no longer knows that $querypattern, coming from $request->getVal() is user-controlled. Others I've seen lately: r959874, r958027.