The current PAM auth bypass query which was contributed by me a few months back, alert on a vulenrable function but does not check if the function is actually function. This leads to a lot of fasle positives.
With this PR, I add a taint-tracking configuration to check if the username parameter can actually be supplied by an attacker.
This should bring the FP's significantly down.
This is a developer QoL improvement, where running codegen will skip
writing (and especially formatting) any files that were not changed.
**Why?** While code generation in itself was pretty much instant, QL
formatting of generated code was starting to take a long time. This made
unconditionally running codegen quite annoying, for example before each
test run as part of an IDE workflow or as part of the pre-commit hook.
**How?** This was not completely straightforward as we could not work
with the contents of the file prior to code generation as that was
already post-processed by the QL formatting, so we had no chance of
comparing the output of template rendering with that. We therefore store
the hashes of the files _prior_ to QL formatting in a checked-in file
(`swift/ql/.generated.list`). We can therefore load those hashes at
the beginning of code generation, use them to compare the template
rendering output and update them in this special registry file.
**What else?** We also extend this mechanism to detect accidental
modification of generated files in a more robust way. Before this patch,
we were doing it with a rough regexp based heuristic. Now, we just store
the hashes of the files _after_ QL formatting in the same checked file,
so we can check that and stop generation if a generated file was
modified, or a stub was modified without removing the `// generated`
header.
Depending on `localFlowStep` meant that this predicate ended up being
recursive with itself (by way of flow summaries which depend on API
graphs, which in turn depend on import resolution).
Changing this to use the simple local flow step predicate that we use
for type tracking should fix this issue.
Java's regular strings are formatted as they appear in source, but we don't easily have this information available in Kotlin. During annotation extraction however it guesses a source rendering because the source is not necessarily available. By formatting to match the annotation extractor, we prepare to ensure consistency with a Java database
when extracting annotations as seen by Kotlin.
