Filter artifacts based on age before validating them.

[asafalgawi]

What would you like to be added?

When ratify performs verification it does so by going over all attached artifacts and if one of them has an artifact type that supports verification it will trigger the matching verifier, if there is more than one artifact of a given type, then all of them will be verified.

Since verification by ratify involves pulling artifacts from the registry, it is a costly operation.

I would like to propose an optional mitigation, the OCI referrers API also provides annotation in the OCI index response it generates, ratify is aware of each image age and can use it to perform some age-based filtration before even pulling the images.
This especially comes in handy in vulnerability verification where the latest artifact is the only important one.

It may even be possible to define several behaviors:

1. Verify all referrers (default for backward compatibility)
2. Latest referrer (only verify the latest image)
3. First successful referrer (the first one to pass validation, by image age)

Anything else you would like to add?

No response

Are you willing to submit PRs to contribute to this feature?

• Yes, I am willing to implement it.

[susanshi]

note from the community meeting discussion. This should be feasible based on spec at https://github.com/oras-project/artifacts-spec/blob/main/manifest-referrers-api.md#sorting-results. We do have a question, if this new configuration is applicable to all artifact vs selected artifact type.

[asafalgawi]

It is hard to imagine a scenario where this setting is not applicable for a given artifacts type.

If we assume that each artifact is complete and correct, there is no reason to verify all artifacts since each new artifact is replacing it's predecessor.

As for the RFC you've shared, I'm not sure this behavior is kept when a registry does not support the referrs API and uses the tag schema method instead.

[yizha1]

Thanks @AsafAlgawi-MSFT. Before implementation, would you mind creating PRs for your proposals and designs?
See proposal examples under https://github.com/ratify-project/ratify/tree/dev/docs/proposals
See design examples under https://github.com/ratify-project/ratify/tree/dev/docs/design

As we will soon release v1.3.0 on Sep 16, so this issue will be planned for v1.4.0, around three months later. Please let us know if you have any comments.

[binbin-li]

It is hard to imagine a scenario where this setting is not applicable for a given artifacts type.

If we assume that each artifact is complete and correct, there is no reason to verify all artifacts since each new artifact is replacing it's predecessor.

As for the RFC you've shared, I'm not sure this behavior is kept when a registry does not support the referrs API and uses the tag schema method instead.

@AsafAlgawi-MSFT thanks for follow-up! Actually for the notation signatures, we cannot just fetch the latest signature. One valid scenario is that an image can be signed by multiple parties, where each party could attach a different signatures to the image. In this case, we have to get all notation signature artifacts instead of the latest one.

[asafalgawi]

@binbin-li wouldn't a better fit in this scenario is to validate all referenced signatures until the first match ?
I mean the order here does not really matter, but from the perspective of less operations against the registry it does.

[asafalgawi]

note from the community meeting discussion. This should be feasible based on spec at https://github.com/oras-project/artifacts-spec/blob/main/manifest-referrers-api.md#sorting-results. We do have a question, if this new configuration is applicable to all artifact vs selected artifact type.

After further inquiry with the owners the distribution spec it seems that sorting was never added to the referrer API spec, this means that all sorting will have to be done in ratify.