Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependency cycles at the package level are not handled #56

Open
andreaphylum opened this issue Jun 23, 2023 · 0 comments
Open

Dependency cycles at the package level are not handled #56

andreaphylum opened this issue Jun 23, 2023 · 0 comments
Labels
bug Something isn't working

Comments

@andreaphylum
Copy link
Contributor

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:

// javascript/project/mod.rs
#[test]
fn test_topo_sort_with_cycles() {
    let pkg1 = || {
        mem_fixture!(
            "package.json" => r#"{ "main": "index.mjs" }"#,
            "foo.mjs" => r#"
                import Pkg2 from 'pkg2'
            "#,
            "index.mjs" => r#"
                function some_function() {
                  const foo
                }

                export function vuln() {
                  some_function()
                }

                export function not_vuln() {
                  console.log("I am invulnerable")
                }
        "#,
        )
    };
    let pkg2 = || {
        mem_fixture!(
            "package.json" => r#"{ "main": "index.mjs" }"#,
            "index.mjs" => r#"
                import { vuln } from 'pkg1'

                vuln()
        "#,
        )
    };

    let vuln_node = VulnerableNode::new("pkg1", "index.mjs", 2, 8, 2, 10);

    let project: Project<_> = PackageResolver::builder()
        .with_package("pkg1", pkg1())
        .with_package("pkg2", pkg2())
        .build()
        .into();
    let reachability = project.reachability(&vuln_node).unwrap();
    let path = reachability.find_path("pkg2").expect("Path not found");
    print_path(path);
}

See also #25.

@andreaphylum andreaphylum added the bug Something isn't working label Jun 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant