to ensure that the call graph seen by type tracking
does not include summary calls resolved by type tracking.
(I tried inserting a similar test into the Ruby codebase,
and it still compiled)
To get this to compile, I had to move the resolution of summary calls
out of the data flow nodes and into the `viableCallable` predicate.
This means that we now have a potential summary call for each
cfg call node. (I tried using the base class, `DataFlowCall`, for this
but calls to `map` got identified as class calls and would no longer
be associated with a summary.)
It is possible that the "NonLIbrary"-layers the were inserted into the
hierarchy can be removed again.
In the hope that this will enable a better one.
It looks like
- type tracking should currently be mutually recursive with data flow
(this needs investigation)
- type tracking already supports special methods
(we should probably have a test for this)
This partly reverts the changes from https://github.com/github/codeql/pull/10252
Although consistency is nice, the new messages didn't sound as natural.
New alert message would read
> Insecure hashing algorithm (md5) depends on sensitive data (password). (...)
I'm not sure what it means that a hashing algorithm depends on data. So
for me, the original text below is much easier to understand.
> Sensitive data (password) is used in a hashing algorithm (md5) that is insecure (...)
Same goes for the other sensitive data queries.
As illustrated when running the python file, the non qualified reads in
the `use` method all refer to the global variables, whereas `ex =
func(baz)` are to the things defined on the class.
The important part of the .expected changes is that the _global_
variable `bar` is used inside the function, whereas it's the local
variable for `foo` (on class scope) that is used inside the function
(which is wrong).
since
- Python 3 is ok from 3.7 onwards
- support for Python 3.6 was just dropped
- we do not actually know the minor version of the analysed code
(only of the extractor)
