docs/vuln.json

[bagder]

Generate and provide CVE information in JSON format

Sample: vuln.txt

Interested in feedback on all details of this.

[icing]

Seems to contain all relevant information. One could enhance individual records with links to the project or its general security policy. Just to be more descriptive and stand-alone.

[jamietanna]

What are your thoughts on producing these in the form of https://ossf.github.io/osv-schema/ to allow easy consumption by things like https://osv.dev ?

[dfandrich]

That's what I just came her to say, too. Might as well use an existing schema that tools are already written to injest.

[bagder]

• fields like ecosystem and purl I don't know what to provide for
• we can't seem to be able to provide a compatible "severity" because we don't do CVSS score and the schema doesn't allow for the basic low/medium/high/critical style we use ?!

[bagder]

Current look: vuln.txt

[dfandrich]

A purl is easy to create; either a Github one or a generic one would work for curl. See https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst and https://github.com/package-url/purl-spec/ for some examples. What about just arbitrarily assigning a CVSS score for each of low/medium/high and just use those? Or is that too specific? Given that CVSS scores seem to be pretty subjective (witness the rescoring going on), maybe this is good enough. "SEMVER" is almost but not quite right for curl; e.g. the 7→8 major version bump, but I think in this context it's the right choice. I think you want the curl vulnerability ID as the "id" field, since that's the one we have control over, and put the CVE in as an alias. .

[dfandrich]

The current output also fails a JSON parser validation: parse error: Expected separator between values at line 13, column 14

[bagder]

A purl is easy to create

Is it? I don't understand what we should use for curl as I don't recognize we are in any of the mentioned ecosystems.

What about just arbitrarily assigning a CVSS score for each of low/medium/high and just use those

I'll try that!

I think you want the curl vulnerability ID as the "id" field

We don't have any other id than the CVE for our vulnerabilities!

The current output also fails a JSON parser validation:

Using what validator? I loaded that version with Firefox with no problems.

Current version: vuln.txt

[dfandrich]

Is it? I don't understand what we should use for curl as I don't recognize we are in any of the mentioned ecosystems.

The latest version of curl would have a PURL of ***@***.***_0_1 and ***@***.***?download_url=https://curl.se/download/curl-8.0.1.tar.xz&checksum=sha256:0a381cd82f4d00a9a334438b8ca239afea5bfefcfa9a1025f2bf118e79e0b5f0 and ***@***.***?arch=amd64 plus a few other less useful types and variants of types, too, by my reading of the spec. Plus, packagers will have their own PURLs for their packages (like ***@***.***?arch=i386&distro=jessie which is an example that comes straight out of the PURL docs) but since those aren't based on pure curl code that we control, they really shouldn't be in a curl security document.

We don't have any other id than the CVE for our vulnerabilities!

I was talking about IDs like adv_20161102A. Hmmm, it looks like recent advisories don't have IDs that like any longer.

Using what validator? I loaded that version with Firefox with no problems.

I originally used jq, but Python's json module also complains. Firefox may be a little too liberal in what it accepts.

[bagder]

I was talking about IDs like adv_20161102A

They are gone since 9602930, August 2018

[bagder]

The latest version of curl would have a PURL of @.***_0_1

So are we always referencing the latest curl version as a "purl" in all vulnerabilities? Or is the package different in different issues? It seems weird to me, either take!

[bagder]

This validates with jq 1.6 for me!

[dfandrich]

My impression about the idea of a PURL is that people (machines?) can talk about specific sets of code (mostly in SBOMs) in an ambiguous way. Build tools can build a list of software dependencies using PURLs that can be cross-referenced to lists of vulnerabilities. For example, when building the curl Docker images, Docker will (can? should?) output PURLs for everything contained in the image. Our Docker image (known as something like ***@***.***?arch=amd64) would have a dependencies list starting something like: ***@***.***_0_1 ***@***.***?download_url=https://curl.se/ca/cacert.pem ***@***.*** ***@***.*** ***@***.*** ***@***.*** ... since it's based on a base Alpine images containing those packages. You would then query a vulnerability database by PURL to see if anything in our Docker image has a known vulnerability. If so, you can know what and when you need to patch/update rebuild and re-release to be safe. I'm not exactly sure how we're supposed to handle aliases (curl v8.0.1 has a github PURL and a generic PURL that refer to exactly the same thing) or how to handle recursive PURL dependencies ***@***.*** depends on the PURL ***@***.***?download_url=https://busybox.net/downloads/busybox-1.35.0.tar.bz2 ). As long as everyone consistently uses one PURL to refer to the same piece of software, and as long as packagers (like Alpine) publish their own vulnerability reports for their packages, this theoretically works. If you want to be even more thorough, you would query Alpine (somehow) to get the PURLs that each of its packages depend on (like that Busybox example) and check those, too, although that would give false positives for packages that have been patched. This whole data flow can also be used to check software licenses, which is what SPDX is supposed to help with. I'm not really up on how far along the tooling is to handle all this, but the ideas are intriguing.

[bagder]

Is it GitHub that replaces a lot of the content in the previous comment with asterisks? It isn't very helpful.

[bagder]

I added a very rudimentary purl field. I can't figure out what more to add there.

[bagder]

This is how it looks now: vuln.txt

[dfandrich]

It looks like Github is censoring my e-mails. Here are the PURLs again, in order, via the web form this time:

pkg:docker/curlimages/curl@244df1c61696?arch=amd64
    pkg:github/curl/curl@curl-8_0_1
    pkg:generic/cacert@2023-04-02?download_url=https://curl.se/ca/cacert.pem
    pkg:docker/alpine@3.16.2
        pkg:apk/alpine/busybox@1.35.0-r1
        pkg:apk/alpine/musl@1.2.3-r4
        pkg:apk/alpine/zlib@1.2.13-r0
pkg:generic/busybox@1.35.0?download_url=https://busybox.net/downloads/busybox-1.35.0.tar.bz2

[bagder]

pkg:github/curl/curl@curl-8_0_1

This shows the problem I've tried to mention:

1. this refers to 8.0.1, not generically "curl". When we talk about a problem that affects 100 curl versions, which of those versions should the purl identifier point to? Or should it point to the latest so that we always update all issues when we do a new release?
2. this refers to a tag on GitHub which is not our actual releases, it's the state of the files when we generated the release - which is why I think we need to go with "generic" and not "github"

[bagder]

This is how it looks now vuln.txt

[bagder]

Now this also creates a single JSON file for every flaw, accessible by replacing .html in the URL with .json.

[bagder]

The plan: I will merge this and let it deploy on the site. It will give everyone a chance to test it out "live" and then we can iterate from that point to further polish it. As I am sure we can.

[dfandrich]

I looked at this part of the OSV spec and the PURL spec and I see what they're trying to do here. The ecosystem+name fields are completely redundant with the purl field (I'm guessing PURL came later so they retrofitted it in). They're using it to identify a package in a distribution without specifying a version; they're using the ranges field for the versions. It looks like the idea is for Debian to say The package pkg:deb/debian/curl is affected by a security vulnerability; these are the specific versions affected: X. Because the package needs to be unambiguously specified, they limit in the spec the type of PURLs allowed to exclude pkg:generic/X since there's no way to unambiguously specify a package with that one without also specifying a version. The spec also makes ecosystem and name mandatory fields, but without allowing any value for ecosystem that is suitable for curl. So, technically speaking, despite the name, the Open Source Vulnerability Format cannot be used for curl in a compliant manner.

I'll ask OSV about this.

[bagder]

I could also add that I didn't add schema_version and probably something else so our JSON objects are not fully compliant.