Component purl vs purlCoordinates

[malice00]

I was looking in the code to maybe fix some issues connected to the ALL-operator in policies, which led me to (among others) #1925.

I though this was maybe a good starting point, but now I do have some questions regarding the fields purl and purlCoordinates in the org.dependencytrack.model.Component class. It looks to me (from looking through my database) that purlCoordinates is always a substring of (possibly even equal to) purl, and it always starts from position 0.

Now, my first question would be: is this correct, or are there cases where this is not valid? If so, then #1925 is indeed a valid issue and can be easily fixed. If not, then the question remains, if there is some valid point to #1925 and if and when 2 Viollations should actually be added to the list.

My second question arose when looking in the class org.dependencytrack.policy.PackageURLPolicyEvaluator, in which the method evaluate is aborted when the purl of the component is null: In case the fields can be different (Q1), is it correct to only check the purl when evaluating?

I'm hoping to get some answers, preferably after a little discussion, so I can 'get my hands dirty' and dive in.

Thanks!

[stevespringett]

Purl does two things. It can identify a component, and it can locate a component. Location, if not the default, is handled with qualifiers. This is the equivalent of a URL querystring. purlCordinates if the first part of the purl containing the ecosystem, optional namespace, name, and version. It does not include any qualifiers. The purpose for having both is to speed up database queries. If I was querying the db using a components purl identity, I can perform an exact match on purlCoordinates which is an indexed field. If I only had a single purl field, DT would have to perform a full table scan when performing the same query, which would negatively impact performance in a big way.

[stevespringett]

Perhaps something like:

if (component.getPurl() != null) { 
    if (component.getPurl().canonicalize().contains(condition.getValue())) { 
        violations.add(new PolicyConditionViolation(condition, component)); 
    } else {
        if (component.getPurlCoordinates() != null) {
            if (component.getPurlCoordinates().canonicalize().contains(condition.getValue())) { 
                violations.add(new PolicyConditionViolation(condition, component)); 
            } 
        }
    }
} 

It should not be possible to have purlCoordinates without also having a purl.

[malice00]

I'm not sure why a table-scan would be required in case of the policy-evaluation -- I assumed I already have the component that needs to be evaluated in hand (fully loaded) and in the code I see no searches being done... But I admit, I haven't had time yet to do more than discuss the issue with you here, so I might be missing something.

As or the code you posted and the comment you added: imho the else-block is totally useless -- if the purl doesn't match, the purlCoordinates will never match, seeing they are a substring of the purl... That's why I mentioned simply only using the purl to evaluate policies. If I'm wrong, could you maybe give me an example of a case where your code would actually be false on the first if but then return true on the last?

[stevespringett]

As or the code you posted and the comment you added: imho the else-block is totally useless

You're right. Get rid of it to read:

if (component.getPurl() != null) { 
    if (component.getPurl().canonicalize().contains(condition.getValue())) { 
        violations.add(new PolicyConditionViolation(condition, component)); 
    }
} 

[malice00]

Thanks, I'll implement this and some tests in the next couple of days!
Thank you for the back-and-forth, just want to make sure I understand the code and don't add anything stupid! :-)

[stevespringett]

And thanks for the contributions. Much appreciated.