fix: fix incorrect skip result evaluation causing false positives in PyPI malware reporting"

[art1f1c3R]

Addressing issue identified in #1027, where skips were being evaluated as false. This PR introduces wrappers passed() and failed() into the ProbLog model that use try_call() statements. Skipped heuristics are no longer defined in the ProbLog model, which is why this try_call() statement is used. This means that evaluating failed(heuristic) will be false if the heuristic passed, or if it was not defined (i.e. was skipped). Similarly, for evaluating passed(), this will be false if the heuristic failed, or if it was not defined. This should handle situations where skips should not cause rules they are part of to trigger. This method was the easiest way to keep as much of the ProbLog model in a static string as possible, without having to perform extensive string operations.

Rule IDs have also been added for debugging purposes, and a method to extract them, so that it is evident what rule was triggered.

[behnazh-w]

Why isHeuristics.WHEEL_ABSENCE.value passed here?

[art1f1c3R]

That's a result of the translation from these combinations:

    (
        HeuristicResult.FAIL,  # Empty Project
        HeuristicResult.SKIP,  # Source Code Repo
        HeuristicResult.FAIL,  # One Release
        HeuristicResult.SKIP,  # High Release Frequency
        HeuristicResult.SKIP,  # Unchanged Release
        HeuristicResult.FAIL,  # Closer Release Join Date
        HeuristicResult.PASS,  # Suspicious Setup
        HeuristicResult.PASS,  # Wheel Absence
        HeuristicResult.FAIL,  # Anomalous Version
        # No project link, only one release, and the maintainer released it shortly
        # after account registration.
        # The setup.py file has no effect and .whl file is present.
        # The version number is anomalous.
    ): Confidence.MEDIUM,
    (
        HeuristicResult.FAIL,  # Empty Project
        HeuristicResult.SKIP,  # Source Code Repo
        HeuristicResult.FAIL,  # One Release
        HeuristicResult.SKIP,  # High Release Frequency
        HeuristicResult.SKIP,  # Unchanged Release
        HeuristicResult.FAIL,  # Closer Release Join Date
        HeuristicResult.FAIL,  # Suspicious Setup
        HeuristicResult.PASS,  # Wheel Absence
        HeuristicResult.FAIL,  # Anomalous Version
        # No project link, only one release, and the maintainer released it shortly
        # after account registration.
        # The setup.py file has no effect and .whl file is present.
        # The version number is anomalous.
    ): Confidence.MEDIUM,
    (
        HeuristicResult.FAIL,  # Empty Project
        HeuristicResult.SKIP,  # Source Code Repo
        HeuristicResult.FAIL,  # One Release
        HeuristicResult.SKIP,  # High Release Frequency
        HeuristicResult.SKIP,  # Unchanged Release
        HeuristicResult.FAIL,  # Closer Release Join Date
        HeuristicResult.SKIP,  # Suspicious Setup
        HeuristicResult.PASS,  # Wheel Absence
        HeuristicResult.FAIL,  # Anomalous Version
        # No project link, only one release, and the maintainer released it shortly
        # after account registration.
        # The setup.py file has no effect and .whl file is present.
        # The version number is anomalous.
    ): Confidence.MEDIUM,

[behnazh-w]

I think in the previous implementation, we wanted to make sure if wheel absence does not fail, we still report as a malicious patterns as long as anomalicious version fails, there is one release, and quickUndetailed matches. With the new declarative approach, do we still need explicitly require passed({Heuristics.WHEEL_ABSENCE.value})?

[behnazh-w]

Can you please add a comment in the code to explain what happens here? I.e., which rules will be selected and how they are combined, e.g., is it enough if one of them is True? What if more than one rule is evaluated to True?

[art1f1c3R]

Commit 12b2c65 should now handle this. The ProbLog model aggregates the results of all of the rules, and a separate query gets the triggered rule IDs.