Feature name: Disclose container build dates

Objective:  Let Quay users determine the approximate age of a container image build.

High-level user story: As a Quay user I want to see the container image build date for containers pushed to / mirrored to / build inside Quay so that I can feed this information in my security processes or simply sort images according to their original build date.

Background: Today Quay only tracks the modification date of images, which for images pushed to / mirrored into Quay corresponds to the date the images were first pushed to Quay. Images build in Quay, have the last modification coincide with the build date because both events happen at almost the same point in time. The actual creation date of the container is not stored, though it is specified as an optional metadata field in both OCI as well as Dockers own image JSON.

Customers need this information for compliance reasons, to reason about security and also to determine overall image age without having to rely on the tag names indicating version numbers or build dates.

End-to-End user scenarios:

Locally built non-manifest list images

1. A Quay user pushes an image they built locally on their machine
2. The image contains a single manifest only because the user did not build the image for multiple architectures or added metadata in the form of additional manifest to it.
3. The user pushes the image to Quay
4. Quay reads the metadata of the image and captures the creation date, typically in ISO 8601 format, and stores it in the database
5. The user can view the image in the registry using the UI or API and retrieve the creation date, which would represent the point in time when the local build process finished assembling the container image tarball
6. The last modification date is still shown and tracked in the UI/API and would independently show the user when the tag was either initially created or moved to a newer manifest inside Quay

Mirrored manifest-list images

1. A Quay users leverages Quay's repository mirroring to mirror images from an external registry into Quay
2. The images mirrored are usually manifests lists, containing manifests for the various supported CPU architectures of this software or additional metadata supplied as child manifests like in-toto attestations
3. The mirroring processes pushes these images into Quay
4. Quay reads the metadata of each individual child manifest and captures the creation dates, typically in ISO 8601 format, and stores them in the database like so::
   • the child manifests creation date is represented with the information from the individual child manifest metadata
   • the parent manifest-list is computed from the newest creation date found among the child manifest
5. The user can view the manifest lists as well as the individual child manifests creation dates, using the UI and the API, alongside the current modification date which still tracks the modification the tags
6. In the UI, the user can sort the image tag list / table view after creation date to find the oldest and newest dates without having to interpret the tag name
7. The last modification date is still shown and tracked in the UI/API and would independently show the user when the tag was either initially created or moved to a newer manifest inside Quay, there is no modification date for child manifests

Images cached inside Quay via pull-through

For these images the build date cannot be captured because at the time of writing the manifest the config layer blob in which the build date metadata is typically stored has not been pulled yet through the cache.

Images built inside Quay

1. A user builds an image using Quay builders
2. after the image build finishes, the processing of the image's metadata regarding the creation date follows the same path as if the image was pushed to Quay with an external client
3. The user can view the image in the registry using the UI or API and retrieve the creation date, which would represent the point in time when the Quay build worker finished assembling the container image tarball

Images without creation dates

1. A user pushes an image without creation date information, e.g. Helm chart OCI images
2. The image is stored in Quay without any creation date captured, the last modification date points to the point in time the image was pushed and records were created inside Quay's database
3. The user can view the image in the registry using the UI or API but the creation date field in the API is non-existent and in the UI there is a text specifying that no creation date was specified in the image metadata
4. The last modification date is still shown and tracked in the UI/API and would independently show the user when the tag was either initially created or moved to a newer manifest inside Quay

Acceptance criteria:

• Quay opportunistically captures the manifest / image creation date
• For manifest lists / multi-arch images, the creation dates of all child entries is captured and the date for the parent list is computed using the newest creation date found among all child manifests

UI implications:

• the UI displays the creation date among the last modification date in the tag list view and allows to sort the list view according to both dates
• creation dates are shown for both, parent manifest lists / multi-arch images and for each child manifest / image
• the UI also displays this information in the tag detail view