You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not currently possible to find reachability for projects that have dependency cycles at the package level, even though they may not necessarily have dependency cycles at the module level.
This is a chicken-and-egg problem: with the current setup, the reachability graph for a package can only be built if the reachability graphs for all of its dependencies have already been built. On the other hand, identifying a runtime cycle false positive is only possible with a graph traversal, which in turn requires a full graph to be built.
One real world example of this shortcoming is in the babel ecosystem: babel-core and babel-register import each other in some spots; it is not clear whether this results in an actual runtime dependency cycle, but at this point we are not able to support it without further research and potentially taking a completely different approach to building the graphs.
It can be shown that, if we were to modify the topological_sort algorithm to skip the cycle check condition and return the computed ordering, the following test would fail despite a path to the target node being clearly present (pkg1/index.mjs:some_function -> pkg1/index.mjs:vuln -> pkg2/index.mjs:vuln) with no actual runtime cycle:
It is not currently possible to find reachability for projects that have dependency cycles at the package level, even though they may not necessarily have dependency cycles at the module level.
This is a chicken-and-egg problem: with the current setup, the reachability graph for a package can only be built if the reachability graphs for all of its dependencies have already been built. On the other hand, identifying a runtime cycle false positive is only possible with a graph traversal, which in turn requires a full graph to be built.
One real world example of this shortcoming is in the
babel
ecosystem:babel-core
andbabel-register
import each other in some spots; it is not clear whether this results in an actual runtime dependency cycle, but at this point we are not able to support it without further research and potentially taking a completely different approach to building the graphs.It can be shown that, if we were to modify the
topological_sort
algorithm to skip the cycle check condition and return the computed ordering, the following test would fail despite a path to the target node being clearly present (pkg1/index.mjs:some_function -> pkg1/index.mjs:vuln -> pkg2/index.mjs:vuln
) with no actual runtime cycle:See also #25.
The text was updated successfully, but these errors were encountered: