Proposal: Add version ranges #93
Conversation
Package-URL by itself isn't very good for reporting about vulnerabilities because it cannot report version ranges. CPE, by contrast, *can* report version ranges. This commit proposes adding version range support to package_URL. I think node-semver is pretty common, so I referenced that; other options are possible too. Note that even if you don't use semver, the version range still works, since hierarchical numbers are very common. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
|
Thanks for the cross-reference! I think this does handle Debian OR. Doesn't "||" provide the same functionality? If not, please enlighten me! Handling epochs is a bigger issue. But epochs work very much like a "hidden 0. prefix" on a typical version number, and people who follow SemVer won't have epochs. So I think this could be easily modified to support that case. Something like "Versions that begin with the form NUMBER: are presumed to have an epoch of that number; if unstated the epoch is 0. Epochs act as the topmost number in a version." I'm absolutely not married to node-semvar range syntax; others would be fine. However, I think it's important to have some syntax for it, and I thought it'd be easier to start with a specific concrete proposal. I did pick node-semvar intentionally. One reason is that it can express some fairly complex situations. For example, it can relatively easily handle the "multiple streams of versions" case. |
|
In addition to the above, one additional aspect that will need to be addressed is the default repository url for each PURL type. Introducing a range may alter where a component is located, so we'll need to specify what that means. E.g.
|
|
@stevespringett - I think that's backwards. Instead, the version numbers necessarily only apply to the given repo URL (default URL if there's a default and no other URL is given, or a specified URL if one is specified). For example, there are many different programs all called "zlib"; some of them have the same underlying origin. If I specify version X.Y.Z, that version number would only apply to the repo URL given. If there's a different repo URL, there's no reason to believe that version X.Y.Z refers to the same thing. |
|
With NIST moving away from CPE to SWID, hows does this impact PURL? |
|
I believe SWID has two big problems: (1) it's a huge XML file, making processing it very inconvenient, and (2) it can't refer to version ranges. This makes moving from CPEs hard. A big advantage of SWID over package-URL is that SWID can refer to closed source software where no VCS or download source is publicly visible. If pURL supports version ranges and has a mechanism for referring to software home pages (or something else that supports closed source software), then package-URL suddenly has big advantages over SWID for many purposes. |
|
Hi David, totally agree - but NIST seems to be hell bound to go with SWID (even though Microsoft doesn't seem to use it any longer) - JC has way more context |
|
David. I think the zlib example is incomplete. To my knowledge, the zlib project does not have a default distribution repository. However, distributions that package zlib and distribute it to Conan, Buckaroo, Anaconda, Debian, Redhat, etc, will have a default repository. I think a cleaner example (and more representative of the majority of software packages) are those that distribute the package to a repository when released. Typically, each ecosystem will have a default package repository. npm.js for Node.js, Maven Central for Java/Maven projects, etc. My prior point was that if you introduce version ranges, we need to also account for how those package versions can be resolved. For example, the https://github.com/everit-org/json-schema/ project previously distributed all their compiled packages to Maven Central. However, Maven Central lacks certain security controls and transparency, so the json-schema project moved the default repository for the project to use Jitpack instead. Newer versions of json-schema are not available on Maven Central. Therefore, version ranges need to account for these scenarios. The first sentence of the PURL spec is:
So location information needs to be addressed in version ranges when the default repository moves between versions. |
|
Also FYI, I chatted with @pombredanne about trying to represent SWID in PURL, and there seems to be interest in that. Also regarding SWID, the attributes of the SoftwareIdentify field can be represented in PURL and can be used for vulnerability use cases - whenever the NVD gets around to supporting it. I have a few different ideas how that can work and will be submitting a PR - however, I've been holding off until #79 is merged. |
|
I agree that this scenario needs to be addressed. However, I think it would be cleaner for people who need to support ranges to also support multiple package urls separated by whitespace. Then you could have a package URL with a version range and refer to a particular location. This also cleanly deals with the case where version numbers are different for different locations, a common challenge. It also deals with the case where there are many different packages that share a underlying problem, for example, a vulnerability in a specification can cause multiple packages with many versions with them to all apply. I think that would be much cleaner than trying to link version numbers and repository locations within a single package URL. |
|
I do agree that it should have ranges I added some reasoning behind it here on one of the OSSF Issues to @pombredanne |
|
As I noted earlier, I'm not married to this specific version syntax. There are several to choose from. Here's another: I think the key is to be able to support a range of version numbers. The "special" case is epoch numbers, which many systems can't handle, but as I noted earlier I think those are relatively easy to add. |
|
@david-a-wheeler first thank you++ for this! I am not too much in favor of overloading the |
|
@stevespringett re:
It makes sense, and in particular how they are compared matters quite a bit.
IMHO in this case location information would come from specifying a
|
|
Hello, maven coordinates of the everit-org/json-schema are quite baroque, mostly because I left everit-org (the company) soon after the first release of the json-schema project. So the history is:
I don't expect any tooling to support it :) |
|
@david-a-wheeler Please see #139 for an extended take on the same topic, but drafted as a separate mini spec. |
| For example, in a vulnerability report it | ||
| may be important to say "versions 1.1.3 through 4.2.6 are vulnerable". | ||
| Ranges may be specified following | ||
| [node-semver](https://github.com/npm/node-semver)i syntax; note that |
There was a problem hiding this comment.
I'm in favor of this choice. Makes my life much easier 😂
There was a problem hiding this comment.
@isaacs I eventually merged https://github.com/package-url/purl-spec/blob/master/VERSION-RANGE-SPEC.rst which is already in use in CycloneDX and CSAF. We needed to design something that works beyond npm, node-semver ranges.
jkowalleck
added
the
PURL core specification
|
@david-a-wheeler I am closing this. There is value to spec an optional qualifier for a version range, in the case we have no version, but I do not want to mix a version range with a plain version in the same PURL component, this is going to be messy. The follow up for the qualifier is in #340 |
Package-URL by itself isn't very good for reporting about
vulnerabilities because it cannot report version ranges.
CPE, by contrast, can report version ranges.
This commit proposes adding version range support to package_URL.
I think node-semver is pretty common, so I referenced that; other
options are possible too. Note that even if you don't use semver,
the version range still works, since hierarchical numbers are very common.
Signed-off-by: David A. Wheeler dwheeler@dwheeler.com