Add purl mapping for cryptopp/crypto++ - #32
Conversation
📝 WalkthroughWalkthroughDebian and Ubuntu ChangesCrypto++ package URL mappings
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@data/cryptopp/crypto`++/purls.yml:
- Around line 1-6: The crypto++ PURL mapping list currently contains five
entries but the PR scope requires six. Update the purls collection in
crypto++/purls.yml by adding the intended sixth ecosystem mapping, or revise the
stated scope to match the implemented count before merging.
- Around line 2-3: Update the Debian and Ubuntu PURLs in the package entries to
percent-encode each plus sign as %2B, preserving the existing package names and
repository prefixes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: c8cf65ee-6283-4c57-baf2-44db00219650
📒 Files selected for processing (1)
data/cryptopp/crypto++/purls.yml
84305b6 to
55704b9
Compare
The purl spec canonically percent-encodes '+' as %2B: the official purl-spec suite's deb build test maps version 1:2.4.47-2+b1 to pkg:deb/debian/attr@1:2.4.47-2%2Bb1, and its roundtrip test asserts the encoded form is preserved rather than normalised back to a literal '+'. The same percent-encoding pass applies to the name component, so the Debian and Ubuntu entries should read libcrypto%2B%2B. The github and rpm entries contain no '+' and are unchanged.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@data/cryptopp/crypto`++/purls.yml:
- Around line 2-3: Update the Debian and Ubuntu PURL entries in the dataset to
preserve raw “++” characters instead of introducing “%2B%2B” encoding. Keep
these mappings consistent with the existing verbatim YAML storage and exact
lookup behavior; do not add a local encoding exception or partial migration.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 9a7bbc04-743c-433d-9610-4672f25af37b
📒 Files selected for processing (1)
data/cryptopp/crypto++/purls.yml
| - pkg:deb/debian/libcrypto%2B%2B | ||
| - pkg:deb/ubuntu/libcrypto%2B%2B |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major
Do not introduce a local PURL encoding exception.
utilities/sqlite_loader.py stores YAML values verbatim, so these rows will be persisted as %2B%2B while existing dataset mappings and exact lookups use raw ++. This can make raw pkg:deb/.../libcrypto++ queries miss these mappings. Either preserve raw ++ here, or make this a dataset-wide migration that updates all raw-plus mappings and lookup/canonicalization behavior together.
Based on learnings, this dataset preserves raw + characters until a dataset-wide canonical-PURL migration is implemented.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@data/cryptopp/crypto`++/purls.yml around lines 2 - 3, Update the Debian and
Ubuntu PURL entries in the dataset to preserve raw “++” characters instead of
introducing “%2B%2B” encoding. Keep these mappings consistent with the existing
verbatim YAML storage and exact lookup behavior; do not add a local encoding
exception or partial migration.
Source: Learnings
The NVD CPE dictionary contains 29 entries for
cpe:2.3:a:cryptopp:crypto\+\+(referenced by CVEs such as CVE-2019-14318), but the dataset currently has nocryptoppvendor folder, so Crypto++ purls resolve to no CPE.This adds
data/cryptopp/crypto++/purls.ymlwith the upstream repository and the distro source packages:pkg:deb/debian/libcrypto++/pkg:deb/ubuntu/libcrypto++(source packagelibcrypto++)pkg:github/weidai11/cryptopp(upstream)pkg:rpm/fedora/cryptopppkg:rpm/opensuse/libcryptoppPer CONTRIBUTING,
cpes.ymlis not included — is that backfilled from the NVD load once the folder exists, or would you prefer it added to this PR?Summary by CodeRabbit