Pkg UUIDs in `[affected]`package description

[nHackel]

Hello,

I was wondering if it would be helpful to include the UUID of a package in the advisory. While names are unique within the General registry, this would allow consumers of the database to distinguish naming conflicts if they use additional registries.

At a quick glance, I think the necessary metadata is already available in the ALL_PKGS vector. I haven't fully checked which parts of the code would need to be adapted, but if this is interesting, I can take another look at it and make a PR

[mbauman]

Yeah, I've been meaning to add the UUIDs to the exported JSONs — at a minimum in the form of a purl. I do want to keep the Markdown/TOML as concise and easy-to-maintain as possible.

It is a good question about supporting other registries. I had initially considered a much more consise TOML table like:

[affected]
URIs = ["< 1.6.0"]

before choosing the current array of tables:

[[affected]]
pkg = "URIs"
ranges = ["< 1.6.0"]

It's very much worth noting that this expands out to the OSV JSON:

            "package": {
                "ecosystem": "Julia",
                "name": "URIs"
                // "purl": "pkg:julia/URIs?uuid=5c2747f8-b7ea-4ff2-ba2e-563bfd36b1d4"
            },
            "ranges": [
                {
                    "type": "SEMVER",
                    "events": [
                        {
                            "introduced": "0"
                        },
                        {
                            "fixed": "1.6.0"
                        }
                    ]
                }
            ]

My thought in doing so is that this provides space for additional optional fields — like uuid and registry (or registries?). This would be backwards compatible — the defaults are General and the uuid from there. I very much appreciate the thought — I want to both limit our scope while making sure we don't make it harder to expand the scope in the future if we want.

One big constraint is in how OSV defines packages. They have an "ecosystem" and then simply lookup names within that ecosystem. There's no capability to have a separate unique ID or allowance for duplicate names. This database is introducing a new ecosystem — named "Julia" — and defines it to have packages with names in the General registry. And on the possibly-duplicate-names front, we're saved by General's policies.

So what would it look like If we added support for other registries here? I think we'd necessarily need to add another ecosystem. The open Julia purl PR is proposing an optional ?repository_url=https://github.com/HolyLab/HolyLabRegistry parameter, but that's not really feasible within the context of OSV to my knowledge. I also don't know how OSV would or could support a registry with duplicate names.

[mbauman]

Adding the purl to the generated OSV JSONs would be a great addition — and should be quite straightforward to implement!

SecurityAdvisories.jl/src/advisory.jl

Line 304 in f1b89cc

# TODO: "purl" => purl(vuln.pkg)

[nHackel]

Ah very interesting @mbauman! Thanks for the all the details. This repo and your comments in the security-dev slack are definitely a nice aggregation and introduction to the advisory topic and ecosystem.

Initially I only thought about something like RenovateBot or Trivy to be able to distinguish between for example a "problematic" HTTP package version of the general registry and a "private" package of the same name in some internal registry.

Since this advisory is intended to be for OSV and the general registry, I would agree that supporting other registries is out of scope. I'd think most other registries would be some closed-source company/project internal setups. And if there other open-source advisories, they could fork and adapt this project.

I'll take a go at adding the purl