Add detection for Recursion in Java

[DarkaMaul]

To prepare for the blogpost publication.

[mschwager]

Overall, this LGTM. I added @GrosQuildu for review too.

This isn't a blocker, but I wonder if we can generalize the RecursiveCallOrderN functionality. It'd be nice to be able to specify arbitrary depth, and have the default value be 4. I think that would end up creating a cleaner query too, but probably requires some more advanced CodeQL functionality. Anyway, I was just curious if you considered this.

Also, have you done any MVRA runs to check for false positives and such?

[GrosQuildu]

I added more tests in one commit (please keep them).

In the second one, I proposed a much-simplified query that finds any recursive loops. From MVRA the query is speedy enough, but returns a lot of false positives. Would be great to limit FPs before publication with at least this heuristic: do not report if there is a depth/level argument (any number) that is changed for any call in the recursion call path.

Moreover, would be nice to print the offensive method and all methods in the call-path, so debugging is easier. We would need to use path-query instead of the problem one. Then we could also trim results by showing only one method from a cycle (e.g., for level1->level2->level3 now we show 3 results).

Added these TODOs in query code.

Lastly, finding unbounded recursive paths with high precision is probably a hard problem. Would be nice to figure additional heuristics to limit false positives. Probably the "call depth depends on user-controlled input" is the useful one, and we can model it in codeql relatively easily.

[GrosQuildu]

TODO

[DarkaMaul]

I could not make this one not be flagged :(

[GrosQuildu]

May need a local data flow; but that's not a very often pattern I guess

[DarkaMaul]

I updated the query to solve massive performance issues (it was timing out on most repositories):

1. The source is now more restricted : instead of trying to store MethodCall, we store Method and already check that they are part of recursions chains (this restricted sources from 600k results to 500 on Elasticsearch)
2. Consider getCallee instead of getCaller to further reduce the number of candidates
3. 😢 Remove the deduplication logic: I have tried several approaches, but they all failed for large codebase. I don't know if it's a bug with isBarrierIn/Out with FlowState, or something I don't understand about how the predicate is resolved.

[DarkaMaul]

Of note, the CI is failing for a Go query :/

[GrosQuildu]

LGTM; we can solve deduplication later. Please open an issue for it and please describe the unsuccessful attempts.

From curiosity, could you check what is the performance and false-positive rate of c3213e4 version?

CI is failing for another query, gonna fix it in a new PR.

[mschwager]

Approving to move forward with external references.

Changes acknowledged.