Ordering-concept: when multiple artifacts of same type are associated to an image

[hectorj2f]

I am wondering how ordering could be implemented to know which artifacts are more recent than other. Let's imagine a scenario where I push an image with one artifact representing the scan report generated that day. One day later, I generate a new scan report that also associate to the same image, but this time with vulnerabilities.

When i am filtering the artifacts linked to this image, how could we detect which is the latest artifact, or in my case, the most recent scan report ?.

I believe this scenario could be also applied to other type of artifacts.

[SteveLasker]

There's been a few ideas bantered around on this.

• The client can create a date, within it's content. and the client can parse the artifact deciding how it wants to handle the ordering. This means there's no generic ordering, as it's tied up within the specific artifactType. The referrers API would not be able to sort the results, as the date is within the content.
• The manifest can have a date associated with it, so it can be returned in date order

The manifest date has some interesting questions.

• Is it the date the manifest was created?
• Is it the date the manifest was uploaded?
• If it's upload date, does the date change when it's promoted to another repo or registry?

What do folks think about letting the client set a date, and specify the date MUST be UTC. But, the registry doesn't do any validation, as it's impossible to know whether it's the first creation of a manifest (artifact), or the artifact is being promoted across registries.

It does mean a malicious client could create an artifact that is a scan result, and it pre-dates another scan result.
I'd posture that this is really a matter of trust, and perhaps you could filter the SBOMs to those that are signed by the entities you trust.

Any other ideas for how dates could be set and trusted?

[SteveLasker]

There's been a few one-off discussions on this item. The challenge is how a registry would know the artifact was first pushed to a registry, vs. promoted across registries. I think we want to say the sorting would be based on the artifact creation date, not the date it happened to be pushed to a registry.
So, while I think we want to write up some guidance, or even spec for how a date would be set by a client, and possibly used to be sorted by the registry (./referrers) API, I believe we're saying this is a client problem for now.
Unless anyone disagrees, or has some ideas on how we could do it differently, I'm moving this out of draft 2.

I'd also make a call out for anyone that would like to write up the proposal.

[hectorj2f]

@SteveLasker It sounds good to me, it makes sense saying that is a client problem for now.

[SteveLasker]

Covered in #82

[SteveLasker]

Closing as this got covered in #82