Use of qualified type names in external flow summary models

[knutwannheden]

Hi!

I am new to CodeQL and I am trying to understand the type signatures returned by the ExternalFlowExtensions::summaryModel predicate. In some cases they appear to be fully qualified, whereas in others they are fully qualified. Im are referring to the models defined here: https://github.com/github/codeql/tree/dffb12070e53e236366b3c0c798a5dbfb2a604e2/java/ql/lib/ext

I would have expected them all to be fully qualified except for maybe references to types in java.lang (unsure about what packages are implicitly imported in Kotlin). But it looks like often the types from java.util are also referred to in an unqualified way and sometimes also other types (possibly when they are declared in the same package as the type the flow pertains to?). Please also note that the types from java.lang are sometimes referred to using an unqualified and sometimes using a qualified type reference.

I would like to understand what the rules are here so that I can properly interpret the type references and match them to the corresponding method declarations.

[atorralba]

Hey @knutwannheden,

This is how it's supposed to work:

• The modeled elements themselves (combination of package, type, subtypes, and name columns) always use the fully qualified name, precisely because the package is part of the model, e.g. java.lang;String;false;toString;...
• Method signatures (which are optional) normally use short type names, although fully qualified type names are allowed too, but not a combination of both, e.g. ...;(String,List,Map);... or ...;(java.lang.String,java.util.List,java.util.Map);...
• Field references in the input and output columns use fully qualified names (e.g. ...;Field[my.package.MyClass.classField];...

Does this match your observations? If not, could you point us to a specific example that doesn't follow these rules?

[knutwannheden]

Hi @atorralba ,

Thanks for your swift response. That already helps me understand things a bit better. Although I am still wondering according to which rules you decide to use all fully-qualified names or all unqualified names in the optional signature when writing these model files.

Having fully qualified names everywhere would be quite helpful, when for example using Java reflection to do a lookup of the respective method. Otherwise the client program may end up having to loop over all the methods to find the desired method, rather than just doing a "direct" lookup (using the respective types). This because the client program doesn't know which exact type for example "Entry" corresponds to (is it java.util.Map.Entry or some other Entry type?). Does that make sense to you?

[atorralba]

Although I am still wondering according to which rules you decide to use all fully-qualified names or all unqualified names in the optional signature when writing these model files.

I think this is left to the model writer's preference.

Having fully qualified names everywhere would be quite helpful, when for example using Java reflection to do a lookup of the respective method. Otherwise the client program may end up having to loop over all the methods to find the desired method, rather than just doing a "direct" lookup (using the respective types).

I don't quite understand which "client program" you're referring to. These summaries are used by CodeQL to recognize flow going in/out/through external libraries when analyzing a codebase, and the intention is that they are written as YAML models that get parsed by ExternalFlowExtensions::summaryModel.

Are you trying to use these models outside of CodeQL?

[knutwannheden]

Yes, I am writing a CodeQL independent program to consume these models, which I understand isn't something you directly aim at supporting. But I would also have expected the consistent use of fully qualified type names to be better for CodeQL.

[atorralba]

This sounds like a feature request, then. May I suggest opening an enhancement-labeled issue in https://github.com/github/codeql/issues/new?

[knutwannheden]

Sounds good. With a few pointers (unless the files are fully manually authored), I may be able to contribute a PR.

[knutwannheden]

Reported here: #12290