Support for other namespaces

[tchoutri]

In #165, @frasertweedale wrote

We are referencing the Hackage namespace. In most cases, the package description contains a reference to the repository.

Is there any chance that there could be a metadata about the package that references the namespace? I'm currently working on Flora integration of advisories and I'd love to be able to fully disambiguate packages hosted by Hackage from package of the Cardano package repository.

Right now I will restrict the advisories to the @hackage namespace, but I'm be delighted to see a field for the namespace / package repository one day. :)

[TristanCacqueray]

It's not presently extensible, but here is where the affected identifier is defined:

security-advisories/code/hsec-core/src/Security/Advisories/Core/Advisory.hs

Line 51 in b6eca11

data ComponentIdentifier = Hackage Text | GHC GHCComponent

[frasertweedale]

Let's look at how we can do this. There are two things to consider - how can we represent it in our tooling (easy), and whether/how we can represent it in OSV (less obvious).

We should also consider whether we should set it up to support arbitrary namespaces (such that, if we want to include another namespace in future no further tooling change is required), or whether it is reasonable to require a tooling change each time a new namespace appears.

[frasertweedale]

Here are some quick thoughts:

Because there is no way to confirm that package x from hackage.haskell.org and package x from Cardano (or any other source) are the same package, we do need a way to disambiguate.

On the OSV schema, the package field has the optional purl (package-url) sub-field, which we currently do not use.
Because the field already exists, to me this seems the most appropriate mechanism to disambiguate between
different sources for Cabal packages on the OSV side. See also: https://github.com/package-url/purl-spec

Note: we chose Hackage as the ecosystem name and that ship has sailed. We can generalise the meaning of this
field to refer to Cabal packages in general, with source/namespace specified in the purl field. Absence of purl field
would imply hackage.haskell.org. If we were starting over, Cabal might have been a better name for the OSV ecosystem,
but this is not a big deal.

In our advisory DB and our native Advisory tooling, we can add a new field to specify the namespace (optional, defaulting to hackage.haskell.org or whatever value has that meaning). We would need to decide whether to:

• Accept arbitrary strings (as long as they conform to the requirements for namespace in the Purl spec). This would mean no tooling changes to admit new sources/namespaces in our advisory DB. (This is my preference; SRT must still review/approve advisories and we can document the known/common namespaces).
• Limit the values to a fixed set of sources/namespaces. Adding new namespaces would require tooling changes, but they would be minimal (add one value to a list / map / enum type).

In either case, no further changes/additions to OSV schema or ecosystem semantics would be needed.

We will need to implement some library support for the Purl spec.

Welcoming your feedback @tchoutri, SRT members, and other interested parties.

[tchoutri]

Because there is no way to confirm that package x from hackage.haskell.org and package x from Cardano (or any other source) are the same package, we do need a way to disambiguate.

You are absolutely right, The Cardano packages have their own sources and versioning schemes (see servant-sever-0.19.2.0.0.0.0.1)

---

See also: package-url/purl-spec

I would like to suggest this scheme:

• pkg:haskell/hackage/[email protected]
• pkg:haskell/cardano/[email protected]

---

Note: we chose Hackage as the ecosystem name and that ship has sailed. We can generalise the meaning of this
field to refer to Cabal packages in general, with source/namespace specified in the purl field. Absence of purl field
would imply hackage.haskell.org. If we were starting over, Cabal might have been a better name for the OSV ecosystem,
but this is not a big deal.

Indeed this is much too restrictive. Maybe heavily promoting purls would be the way forward, so that I may be able to support Cardano and Horizon packages in my data model in an easy manner, in Flora.