nilp0inter / cpe

CPE: Common Platform Enumeration for Python
GNU Lesser General Public License v3.0
92 stars 30 forks source link

Name matching & Wildcards #25

Open damiengermonville opened 10 years ago

damiengermonville commented 10 years ago

Hi

I'm back for another question :) I'm not sure if this is a bug or the expected behavior. When using CPESet to perform name matching, the asterisk alone is considered as a string containing a wildcard instead of the value ANY: https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L201

However, this has (in my opinion) some strange results such as the following:

>>> import cpe
>>> from cpe.cpeset2_3 import CPESet2_3 
>>> c0 = cpe.CPE('cpe:2.3:a:1024cms:1024_cms:1.2.5:*:*:*:*:*:*:*')
>>> c1 = cpe.CPE('cpe:2.3:*:1024cms:1024_cms:1.2.5:*:*:*:*:*:*:*')
>>> CPESet2_3.cpe_superset(c1, c0)
False
>>> CPESet2_3.cpe_superset(c0, c1)
False

In my mind, the first call (_CPESet2_3.cpesuperset(c1, c)) would return True as c0 supersets c1. In fact, the method _CPESet2_3.compare() will return _CPESet2_3.LOGICAL_VALUEUNDEFINED because the target has a value ANY which is considered as a wildcard: https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L95

I managed to get the expected result (still, from what I understood from the specs) by adding the following at the beginning of the _contains_wildcards() method.

        if s == '*':
            return False

Is there any other part of the specs implementation which needs to be fixed ? Or am I completely wrong about CPE name matching :D ?

_Note: my tests were only focused on CPESet23, I haven't had a look at the other versions.

May further testing be needed, please ask :)

Thanks !

damiengermonville commented 10 years ago

Hi again,

I'm using the same issue to report a slight mistake in the CPESet2_3._compare() method (well, if I'm using correctly).

On both lines 105 and 109: https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L105 https://github.com/nilp0inter/cpe/blob/develop/cpe/cpeset2_3.py#L109

The values of attributes (target and source) are compared to CPEComponent2_3_WFN.VALUE_ANY (the 'ANY' string). However, the values received as arguments are not WFN values but FS values, i.e. receives the asterisk char and compares it to 'ANY'.

I think that CPEComponent2_3_FS.VALUE_ANY should be used instead, or that the conversion from FS attributes to WFN attr should be done before.

Again, I only tested that behavior on CPE2_3 objects.

Thanks

timojuez commented 4 years ago

Upvoting the forge by geekoftheweek. Solves the problem.