Issue

After numerous complaints to ProdSec about incorrectly filed CVE trackers or even completely unreported vulnerabilities, we were able to find the root cause. ProdSec uses the Deptopia tool to build a database of components to scan vulnerabilities in. Deptopia scans RPMs for Provides: bundled(...) metadata (it hasn't always been this way, it was probably changed because of inaccurate reporting of Ruby vulnerabilities). Each bundled component has an ecosystem assigned which categorizes it as either generic, gem, pypi and others. ProdSec analysts use 'environment filtering' when looking for affected components. So when a vulnerability for Rack comes in, they filter for environment gem. Because pcs uses Provides: bundled(rack) statement, Deptopia recognizes it as ecosystem generic instead of gem. This is where our metadata is sub-optimal because it doesn't comply with Fedora Packaging Guidelines: If the bundled package also exists separately in the distribution, use the name of that package. Otherwise consult the Naming Guidelines to determine an appropriate name for the library as if it were entering the distribution as a separate package. Deptopia expects either Provides: bundled(rubygem(...)) or Provides: bundled(rubygem-...) style metadata to get the ecosystem right: https://gitlab.cee.redhat.com/product-security/deptopia/deptopia/-/blob/master/internal/sources/rpm_test.go?ref_type=heads#L712-720 https://gitlab.cee.redhat.com/product-security/deptopia/deptopia/-/merge_requests/558 To comply with the packaging guidelines and improve the ability to get accurate trackers, we need to change the metadata to use names as if the package were entering a distribution (python-<libname>). We will not be using the virtual provides style format (python(<libname>)). Acceptance Criteria: 1. Python dependencies use bundling metadata: Provides: bundled(python-<libname>) 2. Ruby dependencies use bundling metadata: Provides: bundled(rubygem-<libname>)  

Release Notes

No. of Comments

Resolution

Unresolved