Feature Overview (aka. goal summary)

This feature aims to introduce "crypto-agility" to Quay by removing the hardcoded assumption that all blob digests and tag references utilize SHA-256.  The primary goal is to enable Quay to ingest, store, and serve container images that utilize SHA-512 (and potentially SHA-384) digests.

This is a critical infrastructure update required to meet Post-Quantum Cryptography (PQC) requirements (specifically CNSA 2.0 expectations) by 2027.  This feature allows Quay admins to configure accepted hash algorithms, enabling a transition period where registries may support SHA-256, SHA-512, or both simultaneously.

Goals (aka. expected user outcomes)

• Crypto-Agility: Users can push and pull images generated with SHA-512 digests using updated container tools (Podman, Buildah, Skopeo).

• Configurable Compliance: Administrators can configure their Quay deployment to enforce specific hash algorithms (e.g., "SHA-512 only" for high-security environments or "SHA-256 and SHA-512" for transition environments).

• Forward Compatibility: The registry infrastructure is decoupled from specific hashing algorithms, allowing for easier adoption of future registered hashes without significant refactoring.

• PQC Readiness: The system meets the cryptographic agility requirements outlined for RHEL 10.4 and the 2027 PQC deadline.

Requirements (aka. acceptance criteria)

1. Configuration:

• Introduce a configuration option (e.g., ALLOWED_HASH_ALGORITHMS) in config.yaml to specify valid hash types.
• Support valid values: sha256, sha512.
• Default behavior should remain sha256 to ensure backward compatibility.

2. Ingestion (Push):

• The Registry API must accept POST requests for upload sessions where the digest is calculated using SHA-512.
• Validate the checksum of uploaded blobs against the declared SHA-512 digest.
• Support "Chunked Uploads" compliant with the emerging OCI distribution-spec updates regarding variable hash algorithms.

3. Storage:

• Database schema must accommodate longer digest strings (SHA-512 is 128 hex characters vs SHA-256's 64).
• Storage backend paths must correctly map content based on the configured hash algorithm.

4. Distribution (Pull):

• Manifests referencing SHA-512 blobs must be serveable to clients.
• Content discovery endpoints must return the correct digest format.

5. Interoperability:

• Must be validated against Podman 6.1, Buildah, and Skopeo generating SHA-512 images.

• Existing SHA-256 images must remain accessible in a "mixed" configuration environment.

6. Not in scope:

• Quay is NOT responsible for automatically converting/rehashing existing SHA-256 images to SHA-512.  The client is responsible for repushing and resigning images if a hash migration is required.

Documentation considerations

• Configuration guide: Update config.yaml documentation to explain the new hash configuration parameters and the implications of restricting allowed hashes.

• Compatibility matrix: Explicitly state which versions of client tools (Podman/Docker/Skopeo) are required to interact with a SHA-512 enabled registry.

• Migration path: Clarify that enabling SHA-512 does not upgrade existing data; it only enables new ingestion.