hohn/codeql
1
0
Fork 0
mirror of https://github.com/github/codeql.git synced 2025-12-24 04:36:35 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #14430 from RasmusWL/api-graph-import-star

Browse Source 
Python: Better allow `import *` to work with API graphs
This commit is contained in:
Rasmus Wriedt Larsen
2023-10-11 10:03:46 +02:00
committed by GitHub
parent e99b1598d1 ee75b104eb
commit 68d00a829e
3 changed files with 26 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
python/ql/lib/change-notes/2023-10-10-api-graphs-import-star.md Normal file
View File

@@ -0,0 +1,4 @@
---
category: minorAnalysis
---
* Added better support for API graphs when encountering `from ... import *`. For example in the code `from foo import *; Bar()`, we will now find a result for `API::moduleImport("foo").getMember("Bar").getACall()`

17
python/ql/lib/semmle/python/dataflow/new/internal/LocalSources.qll
View File

@@ -11,6 +11,7 @@ import DataFlowPublic
private import DataFlowPrivate
private import semmle.python.internal.CachedStages
private import semmle.python.internal.Awaited
private import semmle.python.dataflow.new.internal.ImportStar
/**
* A data flow node that is a source of local flow. This includes things like
@@ -39,6 +40,22 @@ class LocalSourceNode extends Node {
this instanceof ExprNode and
not simpleLocalFlowStepForTypetracking(_, this)
or
// For `from foo import *; foo_function()`, we want to let the variables we think
// could originate in `foo` (such as `foo_function`) to be available in the API
// graph. This requires them to be local sources. They would not be from the code
// just above, since the CFG node has flow going into it from its corresponding
// `GlobalSsaVariable`. (a different work-around is to change API graphs to not rely
// as heavily on LocalSourceNode; I initially tried this, but it relied on a lot of
// copy-pasted code, and it requires some non-trivial deprecation for downgrading
// the result type of `.asSource()` to DataFlow::Node, so we've opted for this
// approach instead).
//
// Note: This is only needed at the module level -- uses inside functions appear as
// LocalSourceNodes as we expect.
//
// TODO: When rewriting SSA, we should be able to remove this workaround
ImportStar::namePossiblyDefinedInImportStar(this.(ExprNode).getNode(), _, any(Module m))
or
// We include all module variable nodes, as these act as stepping stones between writes and
// reads of global variables. Without them, type tracking based on `LocalSourceNode`s would be
// unable to track across global variables.

8
python/ql/test/library-tests/ApiGraphs/py3/test_import_star.py
View File

@@ -2,9 +2,11 @@
from unknown import * #$ use=moduleImport("unknown")
# Currently missing, as we do not consider `hello` to be a `LocalSourceNode`, since it has flow
# going into it from its corresponding `GlobalSsaVariable`.
hello() #$ MISSING: use=moduleImport("unknown").getMember("hello").getReturn()
# This used to be missing, as we did not consider `hello` to be a `LocalSourceNode`,
# since it has flow going into it from its corresponding `GlobalSsaVariable`.
hello() #$ use=moduleImport("unknown").getMember("hello").getReturn()
print(const_from_unknown) #$ use=moduleImport("unknown").getMember("const_from_unknown")
# We don't want our analysis to think that either `non_module_member` or `outer_bar` can
# come from `from unknown import *`