This is only a temporary fix, as indicated by the TODO comment.
The real underlying issue is the fact that `isUnused` is defined in
terms of the underlying SSA variables (as these are only created
for variables that are actually used), and the fact that annotated
assignments are always considered to redefine their targets, which may
not actually be the case.
Thus, the correct fix would be to change the extractor to _disregard_
mere type annotations for the purposes of figuring out whether an
SSA variable should be created or not.
However, in the short term the present fix is likely sufficient.
We were mixing between things, so this is just to keep things
consistent. Even though it's not strictly needed for all queries,
it does look nice I think
We were not supporting `except` statements handling multiple exception
types (specified as a tuple) correctly, instead just returning the
tuple itself as the "type" (which makes little sense).
To fix this, we explicitly extract the elements of this node, in the
case where it _is_ a tuple.
This is a change that can potentially affect many queries (as `getType`
is used in quite a few places), so some care should be taken to
ensure that this does not adversely affect performance.
- `KnownCVEs` contain the currently triaged Python CVEs
- `unittest.py` contains some tests constructed by @erik-krogh
- `redos.py` contains a port of `tst.js` from javascript
The expected file has been ported as well with some fixups by @tausbn
Now there is a path from the _imports_ of the functions that would
return sensitive data, so we produce more alerts.
I'm not entirely happy about this "double reporting", but I'm not sure
how to get around it without either:
1. disabling the extra taint-step for calls. Not ideal since we would
loose good sources.
2. disabling the extra sources based on function name. Not ideal since
we would loose good sources.
3. disabling the extra sources based on function name, for those calls
that would be handled with the extra taint-step for calls. Not ideal
since that would require running the data-flow query initially to
prune these out :|
So for now, I think the best approach is to accept some risk on this,
and ship to learn :)
