Artifact registry object for publishing events

[thompson-tomo]

Looking at the artifact published event one key thing appears to be missing is fields to indicate where the artifact's have been published to.

As such it would be great if we could have a registry object on the artifact published event which describes where the files have been published to.

The properties of registry would be:

• Name
• Url

[davidB]

Hi,

The registry is included in the id of the artifact. The artifact's id follows the PURL specification

And you have registry + repository then some query parameter are used (see syntax & sample for OCI).

you can see how cdviz build artifact's id for package hosted on github at https://github.com/cdviz-dev/cdviz-collector/blob/d9c26533a81b3f2f956a88c30fa7a7d2bd5cad45/transformers/github_events/transformer.vrl#L54

[thompson-tomo]

Hi @davidB

Thanks for that info however purl doesn't provide the necessary information.

The "registry" included in purl is the type of repository rather than a name of the registry. This difference is important as a registry might support multiple package types.

The url of the registry is not included in the id and it doesn't make sense to be included as if the same artifact is published to different registries then the purl would differ hence losing the common id.

[davidB]

Hi @thompson-tomo

The URL / hostname of the registry can be included in PURL. To me, it makes sense to have the location of an artifact and all the necessary information to identify and locate it. Yes, different registries could imply different PURLs, but applications (users of the PURL) are free to ignore the registry information or not (the same namespace, name, and version do not always mean the same artifact, especially when considering the security perspective).

To illustrate the partial artifact identification: in cdviz dashboard, I implemented "partial equals" between artifact Id, because when a container image is published into a registry+repository the digest is used as "version" for PURL (it's the spec) and tags like latest, 0.1.0, ... are defined via qualifier (query parameter) and each tag generate 1 CDEvents. So I have something like pkg:oci/my-app@sha256%3Adbfd...9c?repository_url=ghcr.io/my-org&tag=0%2E1%2E0 (cdviz fully encodes/escapes url part). However, when the artifact (container) is deployed in Kubernetes, for example, only the digest or one tag is used/known. So the artifactId in CDEvent is like pkg:oci/my-app?repository_url=ghcr.io/my-org&tag=0%2E1%2E0. The dashboard "artifact timeline" does a partial match, combining version & tags to be able to link those events.

Sorry if I don't understand your issue. Can you provide an example and use case to illustrate your issue?

[thompson-tomo]

The URL / hostname of the registry can be included in PURL.

Agree that It could but it seems like a misuse of qualifiers given the definition of it is "extra qualifying data for a package such as an OS, architecture, a distro, etc". The registry info doesn't fit in to the same category/class of data.

Yes, different registries could imply different PURLs, but applications (users of the PURL) are free to ignore the registry information or not.

We would then need a way to communicate which qualifiers can be ignored etc and for me it seems to go against the objective of purl which is "A purl is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases."

However, when the artifact (container) is deployed in Kubernetes, for example, only the digest or one tag is used/known.

Yes that would be the case but in that case the digest would become known/resolved based once the search/pull has been performed, hence reducing the need for a fuzzy match.

Can you provide an example and use case to illustrate your issue?

What I want to be able to do is take the artifact published cdevent and produce open telemetry signals (metrics & events). Open telemetry requires a reproducible values especially for entities such as artifact's.

In the end it should be possible to have metrics reporting on the number of artifact's published broken down based on registry, while also allowing search through events to see which registries an artifact has been published to and by extension where it has been installed to.