How to support non-General-Package advisories?

[mbauman]

Right now, this "julia" advisory repository with its JLSEC advisory prefix is defined to support exactly one ecosystem: Julia. And we very intentionally designed that ecosystem to mean exactly the things defined in the General registry (cf. the documented definition here):

Ecosystem	Description
Julia	The Julia Programming Language ecosystem; the name is a registered package in the General registry

I had actually wanted to name the ecosystem the name of our registry (cf. Hackage/CRAN/PyPI/etc) but unfortunately "General" is far too general in the context of such a global namespace, and I had thought that we could (ab)use General itself to cover Julia itself and the stdlibs (#437) if/when we need to. IIRC, I did also consider an ecosystem name like "JuliaGeneralRegistry," but thought it was too inventive and ad-hoc and simply unnecessary when it seemed that the General registry would be able to support what we needed. I do remember considering the GHC/Hackage split that HSEC does, but again thought that was overly complicated. My core consideration was that I wanted the Julia ecosystem to support all the names that appear in a Manifest by default. I very intentionally left other public registries "out of scope" for this effort. My analysis did not consider, however, auxiliary infrastructure sorts of things like juliaup, CI, and the like.

BUT: we now have concrete needs to support more than the General Registry packages. There are at least four things we want to support in addition to General's packages:

• Pkg.jl: PlatformEngines: protect auth token refresh download Pkg.jl#4689 (cf. What to do about stdlibs? #437). Unlike some stdlibs, Pkg is not and has never been listed in General.
• juliaup: Publish JLSEC-2026-609 #547
• Julia CI infrastructure. These could be buildkite plugins or the like.
• Julia deployment infrastructure.
• Julia itself. Due to history, julia is a registered name in the General registry and Pkg considers it a reserved/invalid package name. Its versions are incomplete and stale. I think advisories against stdlibs should also list the julia versions that incorporates them as being affected.
• (possibly) Julia-VS Code? Anything else?

Now... there could be one or more solutions here. Some possibilities include:

• Sham registrations of the names & versions we need in General. I don't like this for any of the above options except perhaps the Stdlibs... but even in that case it's fraught (What to do about stdlibs? #437).
• Adding one or more additional ecosystems. The challenge is that each must carefully define what their names mean and what the versions are. This is precisely what makes having the General registry so useful!
• Add support for OSV ecosystem suffixes. We could have an optional Julia:$registry_url suffix. This was a new discovery to me today as I researched our options; it's what Maven does:

  The [Maven] ecosystem string might optionally have a :<REMOTE-REPO-URL> suffix to denote the remote repository URL that best represents the source of truth for this package, without a trailing slash (e.g. Maven:https://maven.google.com). If this is omitted, this is assumed to be the Maven Central repository (https://repo.maven.apache.org/maven2).

• Theoretically, OSV schema allows empty affected arrays... but it's the very first thing osv-lint checks for!
• Informational advisories aren't really a "thing" but some ecosystems (ab)use them. They're still mostly used for actionable notices, though, like unmaintained/EOL status.
• We could simply create GHSAs and (perhaps) CVEs, and include them here and on our website but not create JLSEC identifiers for them. This is what RustSec does for, e.g., rustdoc and cargo itself (nb. there's also a separate cargo crate, but it's fully distinct). Note that it's not a package! Those aren't RUSTSEC-* advisories, and they're not included in the osv export branch.

[mbauman]

In searching around, I found some other security groups facing similar challenges. This is perhaps the best entry point: ossf/osv-schema#94

One challenge that issue details with phony/alternate ecosystems that aren't Pkg-Registry-based is purl support.