Accept CPE 2.3 locators with unescaped special characters#894
Open
arpitjain099 wants to merge 1 commit into
Open
Accept CPE 2.3 locators with unescaped special characters#894arpitjain099 wants to merge 1 commit into
arpitjain099 wants to merge 1 commit into
Conversation
The cpe23Type validation regex required a literal backslash before the special-character class in two places, so valid CPE 2.3 strings whose version or product field contains a character such as "+" (for example spdx-tools 0.8.3.dev1+g8050fd9c, or libstdc++6) were rejected even though they are well formed per the CPE 2.3 grammar. Drop the stray leading backslash so the special characters match directly. Adds validation cases for "+" in the version and product fields. Fixes spdx#796 Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
cpe23Typevalidation regex (CPE23TYPE_REGEXinexternal_package_ref_validator.py) required a literal backslash immediately before the special-character class, in two places:(\\[\\\*\?!...]). That meant a special character like+had to be backslash-escaped to validate, so well-formed CPE 2.3 strings were rejected when a field contained an unescaped+. Examples from #796:cpe:2.3:a:ahmed_h.:spdx-tools:0.8.3.dev1+g8050fd9c:*:*:*:*:*:*:*(+in the version)cpe:2.3:a:debian_gcc_maintainers:libstdc++6:12.2.0-9:*:*:*:*:*:*:*(+in the product)The fix drops that stray leading backslash so the special-character class is matched directly (
([\\\*\?!...])). The class still contains\, so genuinely escaped sequences keep working; it just no longer requires the escape. Credit to @billie-alsup who pinpointed this in the issue thread.I checked the regex against the reported strings plus the existing valid examples: the three failing cases now match and the previously-passing ones are unchanged. Added two
test_valid_external_package_refcases (+in version and in product);pytest tests/spdx/validation/test_external_package_ref_validator.pypasses (54).This is scoped to the unescaped-special-character problem. The separate empty-field observation in the thread (e.g.
10.04::lts) is left out, since that touches the grammar more broadly and the spec example itself trips it.Fixes #796