Second batch of test reblessings, capturing changes in result content
(not just toString labels):
- Framework taint/concept tests (fastapi, sqlalchemy, aiohttp, lxml,
stdlib, django-orm): mostly gained MISSING-tainted annotations where
the new dataflow no longer reaches sinks. Some are real taint
regressions; left as documented failures for follow-up.
- Exception-handler tests (CWE-209-StackTraceExposure, EmptyExcept,
CatchingBaseException, IncorrectExceptOrder, FileNotAlwaysClosed,
FindSubclass/Find, Statements/exit/UseOfExit): the no-raise shared CFG
abstraction does not emit ExceptionSuccessor abrupt-completion edges
from arbitrary expressions, so except-handler bodies (and their
exception target Names) are statically dead. Tracked separately under
cfg-modelling-exceptions.
- Dataflow-path / control-flow node toString polish across the security
query suite (PathInjection, CodeInjection, UnsafeUnpacking,
UnsafeUsageOfClientSideEncryptionVersion, RequestWithoutValidation,
ReflectedXss, CallGraph): simple-leaf nodes now stringify as their
AST text instead of 'After X'.
- SSA / call-graph improvements (CmpTest, CallGraph/InlineCallGraphTest):
fewer SSA mismatches between new and old; two previously-MISSING tt=
annotations resolved.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Or, more generally, any copy step, as these presumably do not preserve
object identity.
(Arguably, `copy` could still be susceptible to interior mutability, but
I think that's outside the scope of this query anyway.)
There are two issues with `deepcopy` here. Firstly, the `deepcopy` function itself
has a mutable default value in its parameter `_nil` (set to the empty list by default).
Now, this value is never actually returned from `deepcopy`, as it is only used as a
sentinel, but our analysis is not clever enough to see this. Thus, it thinks that this
mutable default is returned, and hence the result of any call to `deepcopy` is a
potential source.
To remedy this, I opted to simply exclude all sources that originate from within the
standard library. It is very unlikely for any of the sources in the standard library
to be legit.
Secondly, `deepcopy` -- by virtue of being a function that we model as preserving
values -- admits data-flow through its calls, but this is not correct for the mutable
default query, as it is here the _identity_ of the default value in question that is
important. Thus, we get spurious flow through `deepcopy` for this specific query.
Moves the existing tests into the `ModificationOfParameterWithDefault` subdirectory
which already contained a bunch more tests. In the process, I also removed some
duplicated test cases.
