-
Notifications
You must be signed in to change notification settings - Fork 30
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
CPEs with just one (or very few?) (wfn) attributes will cause wrong 2.3 uris #28
Comments
(Also I'm not sure if the wfn for just the legacy edition is correct. I'm trying to make sense of NISTIR 7695 if the ANY values in the wfn string are required or not. You seem to assume they are required, at least they're consistently present in every other case.) |
Hi, sorry for the long delay, I'm not having much time lately for maintaining the package. I've merged #29 and uploaded version 1.2.1. I've seen the tests marked as xfail, but I don't know what should be the proper behavior here. Maybe @galindale can help here... |
Hi, I'm afraid the current implementation of the cpe library about WFN to URI conversion is wrong. In the second step of the section 6.1.3.1 called "Summary of algorithm", the standard specification (NISTIR-7695-CPE-Naming) says:
Therefore, the part, vendor, product, version, update and language components must always appear For example, the correct WFN of URI "cpe:/a" is:
not:
It's necessary to review the implementation of converter from URI to WFN with CPEs version 2.3. For instance, I saw that in the line 383 of cpe2_3_uri module there is a wrong continue statement (the attribute is not set) instead of setting ANY value with "v.append(CPEComponent2_3_WFN.VALUE_ANY)". In the case of binding a WFN to a URI some components can disappear if they have empty values. For example:
binds to the following URI (edition part is missing because trailing colons are removed):
I hope my explanation helps you @TauPan. Thank you very much for your pull request and your tests. |
Hm, interesting. Thanks @galindale for pointing out how the reference implementation works. However I see in Section 5.2 (WFN Attributes): So it appears the current implementation conforms to that statement. I think it's a design choice if you want to conform to the reference implementation which is more strict (i.e. not omitting any attributes) or if you want to conform to the more lenient statement that omitting attributes in a wfn is permissible. |
We import a (non-official) dictionary from a corporate security advisory service provider, which contains some generic cpes that just have vendor, product or version set.
(No idea for what internal purpose they're being used at the vendor, but if we import them, they land in our (customers) database.)
I'll work on a PR for this today, but first I wanted to give you a description of the behaviour we see.
(with python 2 in current 1.2.0)
cpe_uri2_3_test.py:
Outputs:
I'll try to come up with testcases and PR later today (since I know your time is constrained and we'd like this to work soonish).
The text was updated successfully, but these errors were encountered: