Tenable and their "p-cpe" invention- would you accept a PR for support in cpe or as a package "extra"

[mzpqnxow]

Hey there, thanks for your work on this project. It's been really useful to me and I'm happy I found it before I tried to write my own CPE parsing, which would have been very hacky :)

The subject is pretty descriptive, but if it's not obvious, I'm asking if you're philosophically opposed to support Tenable p-cpe hack. I have a working implementation of this against the develop branch, as a separate version of CPE2_2. Are you philosophically opposed to having this in the cpe package? If so that's fine and quite understandable

What is p-cpe

This is what the Tenable documentation on p-cpe says, it's pretty straightforward:

There are also p-cpes. This is a unique prefix created by Tenable, which is used for Linux package checks; They are made up of <vendor>:<distribution>:<package>

Some examples of p-cpe values:

p-cpe:/a:canonical:ubuntu_linux:python2.1-gdbm
p-cpe:/a:novell:opensuse:libmbedcrypto3-32bit
p-cpe:/a:fermilab:scientific_linux:libinput
p-cpe:/a:virtuozzo:virtuozzo:nss

Workarounds requiring no changes to cpe package

As a workaround, these can be parsed without any changes to cpe if the user does the following:

1. Strips off the p- prefix; however
2. Handles the mapping of the p-cpe package value will actually be in the version value, because of the cpe apckage adherence to the spec

The first is trivial, the second is also pretty easy but can be clunky depending on how the CPE object is being used

Implementation of p-cpe as enhancements to cpe package

To make this work as a new version (CPE2_2_TENABLE) changes were required to a few of the core cpe classes (e.g. CPE, CPEComponent, CPEComponentSimple) for reasons I can explain if you'd like. There are several ways to approach this, I opted to attempt for the elegant, OOP one but ran into some issues. Other approaches are probably better, but are based on your preferences and don't need to be worked out now

Behavior with enhancements

I implemented explicit support for p-cpe into a fork of the develop branch of cpe so that this works without breaking the support for the standard CPE versions- please don't look at it as it's very ugly right now :)

It looks like this:

In [2]: cpe.CPE('p-cpe:/a:amazon:linux:glibc-langpack-zh', cpe.CPE.VERSION_2_2_TENABLE)
Out[2]: 
hw
 []
os
 []
app
 [
   [
     part = a
     vendor = amazon
     product = linux
     package = glibc-langpack-zh
     other = <UNDEFINED>
   ]
 ]
undef
 []

Do you have any interest in supporting this if I provide an acceptable PR? Alternatives to that would be smaller changes, with a new package (p-cpe) being defined as an "extra" in the cpe setuptools metadata or, of course, making this an entirely separate derivative work with the appropriate license/copyright files intact and having no real integration of the two

Thanks again

[sfc-gh-pkommini]

cc @nilp0inter?

[sfc-gh-pkommini]

@mzpqnxow Is it possible to compare a CPE2.3 with a CPE2.2 or CPE2.2_TENABLE? Essentially are cross-version comparison's supported?

[mzpqnxow]

@mzpqnxow Is it possible to compare a CPE2.3 with a CPE2.2 or CPE2.2_TENABLE? Essentially are cross-version comparison's supported?

@mzpqnxow Is it possible to compare a CPE2.3 with a CPE2.2 or CPE2.2_TENABLE? Essentially are cross-version comparison's supported?

For the Tenable CPE (p-cpe) the answer is no, not really.

This is sort of a point against supporting p-cpe in this package, now that you ask. I hadn't really thought about it, so I'm glad that you did

So, because a p-cpe describes a specific Linux distributions package for a technology (rather than a technology) it's a real mess to try to programmatically (or manually) compare a p-cpe to any of the standard CPE versions.

An example p-cpe illustrates this more succinctly than any explanation I can provide...

The following is how OpenSSL would be described in p-cpe for an Ubuntu system:

p-cpe:/a:ubuntu:canonical:libssl

You can see immediately that:

• The vendor (OpenSSL) is not included; instead, the vendor that maintains the package is used
• The most specific technology name is one chosen by the package maintainers

So the p-cpe for OpenSSL will typically not even contain the substring OpenSSL in ANY of the fields

To try to do comparisons would require a prebuilt mapping of package names to technologies, or some fuzzy matching. We all probably agree that would be outside the scope of the cpe package

One last note- including the actual version of the software in p-cpe wouldn't really even allow comparison- because the distributions backport fixes rather than upgrade. So Ubuntu's OpenSSL package may be 1.0.1b, but it contains all of the security fixes for 1.0.1c, 1.0.1d, ... complete non-starters for comparisons all over the place

Hopefully this answers your question without too much cruft and babbling 😊

[mzpqnxow]

Replying to myself, rather than editing my reply

This is sort of a point against supporting p-cpe in this package, now that you ask. I hadn't really thought about it, so I'm glad that you did

... to clarify, I don't necessarily believe this voids the value of supporting p-cpe in the cpe package, but it certainly sounds like a counterpoint I've received from maintainers on other (unrelated) projects for other (unrelated) PRs/proposals

To try to do comparisons would require a prebuilt mapping of package names to technologies, or some fuzzy matching. We all probably agree that would be outside the scope of the cpe package

On the same theme as my previous clarification; though supporting p-cpe will not allow trivial direct comparisons, it will enable users to develop that capability on their own, without worrying about manually dealing with cracking or producing the p-cpe

... just another day, arguing with myself. I'll stop now before I switch positions again 😊