These sources are now modeled using models-as-data, which (probably
correctly) uses the post-update node as the source. But the deprecated
QL models still exist, so we get two test results for each of these
calls.
Note that we don't create post-update nodes for method receivers if the
call to the method is indirect, via a function variable. We could aim to
do this in future.
We have an operator expression like `x * 5`. We want to follow where the
value of the operator expression goes. We used to follow local flow from
an operand, but now there is flow from that operand to the next use of
the variable. The fix is to explicitly start local flow from the
operator expression.
There are also some expected edge changes due to use-use flow.
Make it sanitize the result of the call rather than the input, so that
further uses of the input are still tainted. This means that it catches
things like `log.Print(fmt.Sprintf("user %q logged in.\n", username))`
where the argument to the LoggerCall contains a StringFormatCall, but
it misses things like `log.Printf("user %q logged in.\n", username)`. So
we extract the logic into a predicate and apply it as a condition in the
sink as well.
The downside of this approach is that if there are two tainted inputs
and only one has a safe format argument then we still sanitize the
result. Hopefully this is rare.
Queries / tests that required changes:
* The CleartextLogging and MissingErrorCheck queries are updated because they assumed def-use flow
* The CommandInjection query works around the shortcomings of use-use flow by essentially reintroducing def-use flow when it applies a sanitizer
* The OpenUrlRedirect query currently just accepts its fate; the tests are updated to avoid excess sanitization while the query comments on the problem. We should choose this approach or the CommandInjection one.