github / github/codeql

Consistently use fully qualified type names in Java external flow method signatures

Abierto
#12,290 1 comentario 0 reacciones 0 asignados Ver en GitHub
enhancement
Lenguaje dominante
CodeQL
Estrellas
10.1k
Forks
2.1k
Merge medio
2 d 15 h
PR fusionados (30 d)
141

Descripción

The data flows described by the YAML files in https://github.com/github/codeql/tree/main/java/ql/lib/ext optionally contain method signatures, when the data only applies to specific overloads of the method by the given name. Typically these signatures have been specified using unqualified type references, as in the following examples: https://github.com/github/codeql/blob/748387a69f68ea6197f207342189a4ede7425538/java/ql/lib/ext/javax.json.model.yml#L6-L7

There are however also many cases, where qualified type names are used. Here are a few examples of this kind: https://github.com/github/codeql/blob/748387a69f68ea6197f207342189a4ede7425538/java/ql/lib/ext/org.springframework.util.model.yml#L95-L97

For the generated data the type references appear to consistently be unqualified.

While I don't know how CodeQL currently consumes these models, I would have expected it to be an advantage to always have fully qualified type references, to be able to unambiguously resolve the type references and in the end the method. Theoretically it would for instance be possible that a given library adds a new overload, where a parameter has the same unqualified name as another overload and that the CodeQL model could then not be resolved unambiguously anymore.

While all these models could probably be processed in an automated manner to consistently use qualified type names, it would probably make sense to introduce checks to ensure that no future models start using unqualified type names again.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.