Fetch OCI image config to reliably determine artifact creation dates instead of relying on time.Now() fallback

[krrish175-byte]

Describe the issue

Currently, when the OCI provider fetches artifact versions (GetArtifactVersions), it relies on the org.opencontainers.image.created annotation in the image manifest to determine the artifact's creation date.

However, many container images are not built with this specific annotation. When it is missing, Minder falls back to assigning time.Now() as the creation date (explicitly marked as a // FIXME: This is a hack in internal/providers/oci/oci.go).

Impact:
If a container image is missing the creation annotation, Minder reports it as being created at the exact moment the query was executed. This creates unreliable data and breaks age-based artifact filtering logic, lifecycle policies, and analytics metrics regarding artifact creation.

Proposed Solution:
Instead of relying solely on the manifest annotations and falling back to a hack, the provider should fetch the actual image configuration blob (application/vnd.oci.image.config.v1+json). According to the OCI Image Format Specification, the config blob natively contains a created timestamp property. By fetching the config blob when the annotation is missing, we can reliably determine the true creation date of the artifact.

To Reproduce

1. Register a container repository (OCI provider) in Minder.
2. Push a container image to the registry that does not contain the org.opencontainers.image.created annotation in its manifest.
3. Have Minder fetch the artifact versions for that container.
4. Observe that the CreatedAt timestamp for the artifact is set to the exact time the fetch occurred (i.e. time.Now()), rather than the actual time the image was built.

What version are you using?

main

[evankanderson]

A few other notes while investigating this:

1. There's currently some hackery in place to deal with signatures-uploaded-before-images and images-uploaded-before-signatures. I'm not sure what the testing status for this is, but different tools (not different registries) will upload either the image first or the signature first when you have both.
2. If we're fetching the content, we might also get HTTP Headers that provide a clue as to when the image was uploaded.
3. At least one tool (ko, which we're using) uses the Unix epoch as a "created" date to enable bitwise reproducibility (i.e. produce the same SHA256 checksum when rebuilding the same source, regardless of the build time).

I'm marking this as P2, because I suspect there's a lot we could do around OCI images, and we don't have a clear design yet to spell out what features are missing to enable useful OCI image tracking. This is also a crowded space, so Minder's value-add may not be as clear as it is with Git forges. (Though compelling use cases would definitely turn my head.)

[krrish175-byte]

Thanks for the context around ko and the upload ordering.

Thinking about compelling use cases for why we would want reliable artifact dates (and why fixing this hack unlocks them):

1. Enforcing Reproducible Builds (The ko use case): You mentioned ko uses the Unix Epoch. If we fetch the actual config blob and correctly parse 1970-01-01, users could actually write a Rego policy in Minder that enforces reproducible builds (e.g., deny if artifact.created_at != 0). Right now, if the annotation is missing, the time.Now() fallback completely masks that the image was built reproducibly.
2. Stale Artifact / Patching Policies: A very common compliance rule is "Deployments to production must have been built in the last 30 days" (to ensure base OS layers have recent security patches). If an image is missing the annotation and we fall back to time.Now(), a 2-year-old vulnerable image will look like it was built today, completely bypassing the policy.
3. Signature Age Correlation: If we are verifying Sigstore signatures, knowing the exact time the image was built vs when the signature was applied is useful for anomaly detection (e.g., an image built 6 months ago that was mysteriously signed today).

But I totally agree that if OCI isn't the primary focus right now compared to Git forges, P2 makes perfect sense! If we do decide to flesh out the OCI tracking design, maybe we can combine fetching the config blob with inspecting the HTTP headers like you mentioned to build a fallback chain (Annotation -> Config Blob -> HTTP Date Header).